JPKCom DB

Fonts — Tipps & Tricks

Kniffe für den Fonts-Tester: Schriften im A/B-Vergleich beurteilen, Glyph- und Schnitt-Fallen, Datenschutz, clamp() mit WCAG-Blick und Typo-Skala.

Zurück zur Übersicht: Fonts · Tool live öffnen: www.jpkc.com/tools/fonts/

Das Manual erklärt jede Funktion, die Beispiele zeigen die Abläufe. Hier geht es um das, was beides voraussetzt: worauf du beim Vergleichen wirklich achtest, welche Fallen das Tool hat und wie du den Datenschutz im Blick behältst. Die Oberfläche ist auf Englisch — die echten Labels stehen deshalb im Original.

Schriften klug vergleichen

  • Vergleiche an deinem Text, nicht an „AaBbCc". Die editierbaren Zeilen im Specimen-Tab und das Editable Sample Layout gibt es genau dafür: Tipp deine echte Überschrift, deinen echten Markennamen, deinen echten Fließtext ein. Eine Schrift, die im Musteralphabet glänzt, kann an deinem konkreten Wort kippen — und umgekehrt.
  • Vergleiche nebeneinander, nicht nacheinander. Leg die beiden Kandidaten über den Schalter Font A / Font B (compare) in die zwei Slots und öffne den Tab Compare A / B: eigener Mustertext, eine Größe für beide und ein Absatz Fließtext Seite an Seite. Das Gedächtnis täuscht beim Hin-und-her-Laden mehr, als du denkst (siehe Beispiel 1).
  • Achte auf den Slot, bevor du klickst. Jede Auswahl landet im gerade aktiven Slot. Wer nach dem Vergleich zurück zu Specimen oder Layout will, schaltet auf Font A um — diese Tabs zeigen nur Font A.
  • Beurteile in Lesegröße, nicht nur groß. Display-Größen schmeicheln. Die entscheidende Frage ist oft, wie eine Schrift bei 14–18 px im Absatz wirkt — dafür hat die Specimen-Tabelle die kleinen Stufen.
  • Halte einen System-Font als Bezugspunkt daneben. Leg eine Systemschrift wie Georgia oder Segoe UI in Slot B. Wenn deine Wunschschrift gegenüber einem soliden System-Font keinen klaren Vorteil bringt, sparst du dir mit der System-Variante einen Web-Font-Download.
  • „not installed" ernst nehmen. Die Systemliste markiert Schriften, die auf deinem Gerät fehlen. Wählst du so eine, siehst du nur die Ersatzschrift des Browsers — und deine Besucher auf anderen Systemen sehen womöglich wieder etwas anderes. Für einen belastbaren Vergleich nimm eine installierte Schrift oder die Datei selbst über Font file.

Glyphen und Schnitte — die häufigen Fallen

  • Prüf immer die Glyph-Abdeckung, bevor du dich festlegst. Gerade junge oder dekorative Google-Fonts decken oft nur das Grundalphabet ab. Im Glyphs-Tab siehst du an Zellen, die in einer Ersatzschrift oder als Notglyph erscheinen, sofort, ob ß, die Umlaute, das Euro-Zeichen oder die typografischen Anführungszeichen fehlen.
  • Achte bei Google Fonts auf die gesperrten Gewichts-Buttons. Sie sind keine Macke, sondern eine Information: Sie zeigen die Schnitte, die diese Schrift nicht hat. Brauchst du ein Light (300) oder ein Black (900), das ausgegraut ist, scheidet die Schrift aus — oder du lebst mit dem Ersatz: Statt eines fehlenden Light zeigt der Browser den nächstliegenden vorhandenen Schnitt, statt eines fehlenden Black ebenfalls einen vorhandenen oder einen künstlich verfetteten.
  • Synthetische Schnitte bei System, Datei und Stylesheet täuschen. Liegt eine Schrift aus den Quellen System, Font file oder Stylesheet URL in Slot A, sind alle 18 Gewichts-Buttons aktiv. Das heißt nicht, dass die Schrift alle Schnitte echt mitbringt — fehlt ein Schnitt, nimmt der Browser den nächstliegenden vorhandenen; nur fette Gewichte und Kursiv rechnet er künstlich nach (faux bold/italic). Eine einzelne Datei wie Brand-Regular.woff2 meldet das Tool als genau einen Schnitt mit Gewicht 400 an: 100 bis 500 zeigen dann unverändert diese Regular, 600 bis 900 und Kursiv sind synthetisch. Verlass dich auf das, was du lizenziert und eingebunden hast, nicht auf den Button.
  • Die Buttons richten sich nach Font A. Im Vergleich gilt ein gewählter Schnitt für beide Spalten, freigeschaltet wird aber nur nach den Schnitten von Font A. Hat Font B den Schnitt nicht, siehst du dort einen Ersatz: den nächstliegenden echten Schnitt oder, bei Fett und Kursiv, einen künstlich erzeugten — leg im Zweifel die Schrift mit weniger Schnitten in Slot A.
  • Bleibt der Status auf „loading…" oder meldet „did not load within 10 s", glaub der Vorschau nicht. Das Tool meldet „loaded" erst, wenn der Browser die Schrift wirklich darstellen kann. Bis dahin zeigt die Vorschau die Ausweichschrift, und jede Beurteilung wäre eine Beurteilung der falschen Schrift.

Datenschutz im Blick behalten

  • Eine Google-Font-Vorschau kontaktiert Google. Sobald du eine Google-Schrift anzeigst, lädt dein Browser sie direkt von fonts.googleapis.com und fonts.gstatic.com — Google sieht dabei deine IP. Für eine kurze Vorschau ist das unkritisch. Für die Produktion gilt aber die übliche Lehre: Web-Fonts selbst hosten, statt sie live von Google einzubinden, sonst ist der Einbau DSGVO (öffnet in neuem Tab)-relevant.
  • Stylesheet-URLs gehen an ihren Anbieter. Eine im Reiter Stylesheet URL geladene Adresse ruft dein Browser ebenfalls direkt ab — der Anbieter (Adobe, Bunny, dein CDN) erhält einen Request mit deiner IP. Das ist beim Testen gewollt, aber gut zu wissen.
  • Die Schrift-Liste ist unkritisch. Suchen und Filtern in der Google-Liste läuft über eine vom Tool-Server zwischengespeicherte Liste, nicht über Google. Erst das Anklicken einer Schrift löst den Google-Request aus.
  • Unveröffentlichte Schriften gehören in den Reiter Font file. Eine Hausschrift oder eine Schrift unter NDA musst du nicht auf ein CDN legen, um sie zu testen: Lokale Dateien liest der Browser selbst ein, sie verlassen deinen Rechner nicht.

Den Clamp()-Rechner richtig nutzen

  • Starte mit einem Preset, dann feintune. Die Type-Scale-Presets (Small bis Display) setzen dir sinnvolle Größenpaare in rem vor; danach passt du die Werte an dein Design an. Das ist schneller, als bei null zu beginnen.
  • Bleib bei der 2,5-Grenze. Ist die größere Größe mehr als das 2,5-Fache der kleineren, warnt der Rechner: Ein großer vw-Anteil reagiert kaum auf Browser-Zoom, der Text erreicht dann womöglich keine 200 % (WCAG 1.4.4). Verkleinere lieber die Spanne, statt die Warnung zu ignorieren.
  • Gib rem aus, nicht px. Die Voreinstellung rem (recommended) hat einen Grund: rem-Grenzen wachsen mit, wenn Nutzerinnen und Nutzer die Standardschriftgröße im Browser hochsetzen; px-Grenzen bleiben stehen. Die px-Ausgabe ist für Fälle gedacht, in denen dein Projekt bewusst in px rechnet.
  • em heißt hier: relativ zur Root font size. Der Rechner rechnet em-Eingaben wie rem um, denn den Kontext des Elternelements kennt er nicht. Steht dein Element in einem Container mit abweichender Schriftgröße, rechne die Werte vorher auf rem oder px um.
  • Schrumpfende Größen sind erlaubt. Trägst du am größten Viewport einen kleineren Wert ein, wird die Schrift auf breiten Bildschirmen kleiner — der Rechner setzt die Grenzen trotzdem korrekt und weist darauf hin. Sinnvoll ist das etwa für riesige Display-Zeilen, die auf dem Handy den Bildschirm füllen sollen.
  • Setz den Viewport-Bereich realistisch. Min Viewport 320 px und Max Viewport 1440 px decken die meisten Fälle ab. Setzt du das Maximum zu hoch, wächst die Schrift auf normalen Bildschirmen kaum; setzt du es zu niedrig, ist sie auf großen Monitoren schon am Anschlag.
  • Vertrau der Live-Preview, nicht nur der Zahl. Zieh das Browserfenster schmal und breit und beobachte den Vorschautext. Die Anzeige nennt dir die aktuelle Viewport-Breite und die resultierende Größe — so siehst du, ob die Spanne zwischen Min und Max angenehm interpoliert oder zu abrupt springt.
  • Hol dir die passende Code-Form. Brauchst du den Wert als Design-Token, nimm aus dem Code Examples-Akkordeon die CSS-Custom-Property; arbeitest du mit Tailwind, die Arbitrary-Value-Klasse; im Sass-Projekt die Funktion fluid() für Dart Sass. Du musst den clamp()-Ausdruck nicht von Hand in dein Format übersetzen (Schritt für Schritt in Beispiel 5).
  • Tailwind-Klasse nicht „aufräumen". In text-[length:clamp(…_+_…)] stehen Unterstriche statt Leerzeichen, und length: sagt Tailwind, dass eine Größe gemeint ist. Fügst du Leerzeichen ein oder lässt length: weg, erzeugt Tailwind keine oder die falsche Regel.
  • Eine Skala statt Einzelwerte. Für ein ganzes Projekt ist die Fluid type scale unter dem Rechner meist der bessere Weg: Basis und Verhältnis je Viewport festlegen, Copy CSS klicken, und alle Stufen von --step--2 bis --step-5 hängen an denselben Parametern (Beispiel 7). Ein kleineres Verhältnis am kleinen Viewport hält die Überschriften auf dem Handy kompakt.

Mit anderen JPKCom-Tools kombinieren

  • Schrift gefunden? Jetzt die Farbe dazu. Schrift und Farbe entscheiden gemeinsam über den Ton eines Designs. Mit Colors baust du die passende Palette zum Schriftbild.
  • Web-Font eingebunden? Prüf die Einbindung. Ein Font-Stylesheet im <head> kann das Rendern blockieren. Der SEO & GEO Analyzer zeigt dir an einer echten URL, ob dein Font-Stylesheet als render-blockierende Ressource eingebunden ist und welche Resource Hints (preload, preconnect) gesetzt sind. Die Schriftdateien selbst ruft er nicht ab und misst sie nicht.
  • Glyphr Studio für den Editor-Schritt. Willst du eine Schrift nicht nur testen, sondern anpassen oder selbst zeichnen, führt der Link am Seitenende zum externen Editor Glyphr Studio (öffnet in neuem Tab) (englisch).

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jede Funktion und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.