URL-Slug-Generator

Verwandeln Sie beliebigen Text in einen URL-tauglichen Slug.

Nur Browser, dein Text verlässt nie dein Gerät


Was ist ein URL-Slug?

A slug is the human-readable, URL-safe path segment that identifies a page within a site. It sits at the tail of the URL and replaces what would otherwise be an opaque database identifier with a descriptive token. In https://example.com/blog/2026/my-awesome-post, the slug is my-awesome-post. Mechanically, a slug is the output of a deterministic transformation: take an arbitrary input string, strip everything that isn't allowed in a URL path segment, fold case, replace whitespace with a separator, and emit ASCII. The transformation is one-way in practice, you can't reliably reconstruct "My Awesome Post: Take Two!" from my-awesome-post-take-two: which is why slugs are stored alongside the original title, not in place of it.

Gute Slugs verwenden nur Kleinbuchstaben, Zahlen und Bindestriche. Sie entfernen Akzente, Sonderzeichen und überflüssige Leerzeichen. Das verbessert sowohl SEO als auch Bedienbarkeit · Suchmaschinen und Menschen können die URL lesen und den Seiteninhalt verstehen.

Woher das Wort kommt, Redaktionsstuben des 19. Jahrhunderts

Das Wort ist ein Jahrhundert älter als das Web. In den Setzräumen der Linotype-Ära wurde jede Zeile Schrift als ein einziger Metallstreifen gegossen (ein „slug“) etwa dreißig Picas breit und gut zwölf Unzen Blei schwer. Der Begriff wanderte dann zur Bedeutung des kurzen Identifiers, den ein Redakteur oben an eine Story schrieb, um sie durch die Produktion zu kennzeichnen: ein ein- oder zweiwortiger Handle wie mayor-budget oder school-fire, den Journalisten, Sub-Editoren und Drucker verwenden konnten, um auf die Story zu verweisen, ohne die volle Schlagzeile zu tippen. AP- und Großzeitungs-Stilbücher dokumentieren die Verwendung bis heute.

Als Movable Type, WordPress und die frühen Django-Docs Anfang der 2000er „slug“ als Feldnamen übernahmen, liehen sie sich den Begriff aus der Redaktion eins zu eins aus. Djangos Dokumentation nennt das Feld slug mindestens seit der 0.91-Veröffentlichung 2005, mit der jetzt kanonischen Definition: ein kurzes Label, das nur Buchstaben, Ziffern, Unterstriche oder Bindestriche enthält, in der Regel in URLs verwendet. Die Metapher trifft, weil sowohl der bleigegossene Slug als auch der URL-Slug kurze, eindeutige, maschinenfreundliche Tokens sind, die auf etwas Längeres zeigen.

RFC 3986 und der Satz unreservierter Zeichen

URL syntax is defined by RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax"), published January 2005 by Tim Berners-Lee, Roy Fielding and Larry Masinter, replacing RFCs 2396 and 2732. It is an STD 66 Internet Standard, the IETF's highest maturity tier, reserved for protocols of demonstrated stability and broad implementation. Section 2.3 of RFC 3986 defines the unreserved characters, the only characters that are guaranteed to be safe in any URI component without percent-encoding: A-Z, a-z, 0-9, hyphen, period, underscore, and tilde. That's sixty-six characters total. Everything else is either a reserved character (with structural meaning in some URI component) or "other", anything in the latter group must be percent-encoded if it appears in a URI.

Da der unreservierte Satz der einzige ist, der durch jeden URI-Parser, der je geschrieben wurde, garantiert sauber round-trippt, konvergieren Slug-Generatoren auf eine fast identische Pipeline: alphabetische Zeichen klein schreiben, Ziffern behalten, Bindestriche behalten, Whitespace durch einen einzelnen Bindestrich ersetzen, und alles andere entweder strippen oder transliterieren. Unterstrich, Punkt und Tilde sind technisch erlaubt, werden in Slugs aber konventionell vermieden, Punkt kollidiert mit Dateiendungen, Tilde liest sich in alten URL-Konventionen als Home-Verzeichnis, und Unterstrich verliert aus den unten behandelten SEO-Gründen gegen Bindestrich.

„Cool URIs Don’t Change“, Berners-Lee, 1998

Tim Berners-Lees Stilnotiz „Cool URIs Don’t Change“ von 1998, gehostet auf der W3C-Site, ist das meistzitierte Stück Slug-Philosophie, das je geschrieben wurde. Die Eröffnungszeile ist berühmt: ein cooler URI ist einer, der sich nicht ändert. Die Notiz liest sich dann als Polemik gegen URL-Designs, die vorübergehende Implementierungsdetails in den Path einbacken. Die empfohlenen Don’ts haben die Slug-Praxis seit fast dreißig Jahren geprägt: keine Authoring-Tool-Endungen in die URL (sie verraten die Implementierung und brechen, wenn man migriert; keinen Status in die URL) Seiten verlassen „aktuell“, aber die URL sollte das nicht; keine Autorennamen, Autoren ziehen weiter; keine Daten, es sei denn, das Datum ist fundamental für die Ressource; keine Session-IDs, Query-Parameter oder Login-Status in eine kanonische URL.

Der Slug (die beschreibenden, semantischen, kleinbuchstaben-bindestrich-Wörter) ist genau das, was in einem „coolen“ URI erlaubt ist. Alles andere ist strukturelle Dekoration, die nicht in die Adresse durchsickern sollte. WordPress’ Permalink-Design, Djangos SlugField und Rails’ to_param verinnerlichen alle diese Anleitung: eine URL ausgeben, die die Bedeutung der Seite ist, nicht die Mechanik, wie sie ausgeliefert wird.

Bindestriche schlagen Unterstriche, und es ist dokumentiert

In einem WebmasterWorld-Interview von 2005 sagte der Google-Ingenieur Matt Cutts, dass Bindestriche von Googles Tokenizer als Worttrenner behandelt werden, während Unterstriche Wortverbinder sind. Also wird green-apples als die zwei Tokens green und apples gelesen, während green_apples als der einzelne Token green_apples gelesen wird. Für die Suchanfrage „green apples“ würde die URL mit Bindestrichen den Titel-Keyword-Check matchen; die mit Unterstrichen nicht. Cutts hat das 2007 in seinem Blog und in einem Google-Webmaster-Help-Video von 2011 auf YouTube („Underscores vs. dashes in URLs“) erneut aufgegriffen, denselben Rat bekräftigt und angemerkt, dass Google irgendwann erwogen hatte, das Unterstrich-Verhalten zu ändern, sodass auch er als Trenner wirkt, es aber nicht getan hat, weil es zu viele bestehende URLs gebrochen hätte, die Unterstriche absichtlich als Verbinder nutzten (__init__.py, Funktionsnamen aus der Programmierung).

Googles aktuelle Seite „URL structure best practices for Google Search“ empfiehlt Bindestriche direkt: eine URL wie /green-dress.html ist nützlicher als /greendress.html, und man sollte Bindestriche statt Unterstriche verwenden. Die Empfehlung ist seit über zwanzig Jahren durchgängig dokumentiert. Der Effekt pro URL ist klein, summiert sich aber über eine Site mit tausenden Seiten, und Bindestriche in Unterstriche zu wandeln hat keinen Vorteil, es gibt kein SEO-Szenario, in dem Unterstriche gewinnen. Jeder glaubwürdige Slug-Leitfaden endet mit dem gleichen Rat: Bindestriche verwenden.

Unicode-Normalisierung, wie NFD Akzente entfernt

Der Unicode-Standard definiert zwei Wege, viele akzentuierte Zeichen zu codieren: präkomponiert (ein einzelner Code Point, wo é U+00E9 ist) und dekomponiert (ein Basisbuchstabe gefolgt von kombinierenden Zeichen, wo é U+0065 plus U+0301, der kombinierende Akut, ist). Visuell identisch, byteweise verschieden. Unicode Technical Standard #15 definiert vier Normalisierungsformen (NFC, NFD, NFKC, NFKD) und für die Slug-Generierung ist NFD der Hebel. Wenn man eine Eingabezeichenkette nimmt, sie auf NFD normalisiert und dann jeden Code Point im Unicode-Bereich U+0300 bis U+036F (den Block der Combining Diacritical Marks) entfernt, bekommt man den ASCII-Basisbuchstaben zurück. Café wird zu cafe, naïve zu naive, François zu Francois, niño zu nino, crème brûlée zu creme brulee.

NFD faltet keine Zeichen, die nicht in Basis+Markierung zerlegbar sind. Das deutsche ß (Eszett) zerfällt unter NFD nicht zu ss: es erfordert explizite Transliteration. Das polnische ł (l mit Querstrich) zerfällt nicht zu l. Das norwegische ø zerfällt nicht zu o. Das isländische þ (Thorn) und ð (Eth) brauchen Lookup-Tabellen. Browser unterstützen String.prototype.normalize() seit ungefähr 2015 (Chrome 34, Firefox 31, Safari 10) nativ, deshalb können selbst kleine JavaScript-Slugify-Utilities die Diakritika-Strip-Arbeit ohne Bibliothek leisten.

Die slugify-Bibliotheksfamilie, was jedes Ökosystem ausliefert

Djangos django.utils.text.slugify() ist seit den frühen 2000ern im Python-Framework. Es schreibt klein, entfernt Zeichen außerhalb von [A-Za-z0-9_-] und ersetzt Whitespace durch Bindestriche. Seit Django 1.9 (2015) schaltet ein allow_unicode=True-Schlüsselwort in einen Unicode-bewussten Modus, der nicht-ASCII-Buchstaben erhält. Es ist die Referenzimplementierung, die alle anderen kopieren. In Node.js ist Sindre Sorhus’ @sindresorhus/slugify das meistheruntergeladene Slugify-Paket auf npm, mit Millionen wöchentlicher Downloads, Features sind lesbare Trenner, anpassbare Ersetzungen (sodass man & auf and, @ auf at mappen kann), Unicode-Handling und locale-bewusstes Kleinschreiben (türkisches I mit/ohne Punkt, deutsches ß → ss). Für Python-Nutzer, die Django nicht verwenden, wickelt Val Neekmans python-slugify auf PyPI die Transliterationsbibliothek unidecode ein und ergänzt slug-spezifisches Verhalten: Regex-Wortteilung, Ersetzungszeichen, Maximallänge, Stop-Word-Entfernung.

Andere Ökosysteme folgen demselben Muster. PHP hat Cocurs cocur/slugify auf Packagist, verwendet von Laravel- und Symfony-Plugins, und Symfony selbst liefert seit Version 5.0 einen AsciiSlugger in symfony/string. Ruby on Rails verwendet String#parameterize, eingebaut in ActiveSupport mindestens seit Rails 1.0; das Gem friendly_id setzt darauf Historien-Tracking und Kollisionsbehandlung. Go hat gosimple/slug mit Locale-Tabellen für über achtzig Sprachen. Rust hat den slug-Crate. Java hat Apache Commons Text und slugify-jvm. Bemerkenswert ist, wie konvergent die API ist: Eingabezeichenkette rein, Slug-Zeichenkette raus, mit der gleichen Handvoll Optionen, Trenner, Maximallänge, Kleinschreibung, Locale. Absolutools Werkzeug sitzt in derselben Familie, läuft aber vollständig in deinem Browser, ohne Bibliothek zu installieren.

WordPress: 43 % des Webs lassen diese Pipeline laufen

WordPress ist das größte einzelne Slug-emittierende System im Web, laut der W3Techs-Umfrage 2026 treibt es etwa 43 % aller Websites an, sodass seine Slug-Konventionen für die meisten Leser effektiv die Slug-Konventionen des Webs sind. Wenn ein Beitrag gespeichert wird, generiert WordPress den Slug automatisch aus dem Titel über sanitize_title() (das im Standard-Rewrite-Fall sanitize_title_with_dashes() aufruft): kleinschreiben, HTML strippen, Entities dekodieren, Whitespace und die meiste Interpunktion durch Bindestriche ersetzen, unsichere Zeichen percent-encodieren, benachbarte Bindestriche zusammenklappen, führende/nachfolgende Bindestriche trimmen. Wenn das Ergebnis mit dem Slug eines bestehenden Beitrags kollidiert, hängt WordPress -2, -3 usw. an. Der Slug ist im Beitragseditor editierbar, sobald ein Beitrag veröffentlicht ist, bricht das Ändern des Slugs jeden bestehenden Link, es sei denn, der Herausgeber richtet eine Weiterleitung ein. WordPress hat historisch nicht-ASCII-Zeichen standardmäßig nicht transliteriert; es percent-encodierte sie, was die berüchtigt hässlichen kyrillischen URLs wie %D0%BF%D1%80%D0%B8... produzierte, für deren Behebung Plugins wie Cyr-To-Lat geschrieben wurden.

Jenseits des Lateinischen: Transliteration für Kyrillisch, CJK, Arabisch

NFD handhabt nur Zeichen, die in ASCII-Basis + kombinierende Zeichen zerfallen. Für nicht-lateinische Schriften braucht die Slug-Pipeline Transliteration: eine Abbildung von jedem nicht-lateinischen Zeichen auf sein lateinisch-schriftliches Äquivalent. Die kanonische Python-Bibliothek ist unidecode, ursprünglich ein Port von Sean M. Burkes Perl-Text::Unidecode aus 2001, das praktisch jedes Zeichen der Basic Multilingual Plane auf eine Best-Guess-ASCII-Zeichenkette abbildet: Москва → Moskva, Αθήνα → Athena. Der CJK-Fallback ist der umstrittene Teil: unidecode verwendet Mandarin-Pinyin für alle CJK-Zeichen, weil Chinesisch die größte CJK-Zeichenabdeckung hat, was unsinnige Romanisierungen für Japanisch produziert (東京 → Dong Jing in Pinyin, nicht Tokyo). Japanisch-spezifische Tools wie pykakasi leisten die Arbeit, Kanji + Kana in echtes Rōmaji zu konvertieren. Die International Components for Unicode (ICU) Bibliothek, gepflegt vom Unicode Consortium und IBM, bietet eine Transliterator-API mit benannten Regelsätzen wie Russian-Latin/BGN, Greek-Latin/UNGEGN und Han-Latin, die offizielle Romanisierungsstandards umsetzen. Absolutools Werkzeug sitzt am leichteren Ende: es faltet lateinische Diakritika über NFD und verwirft den Rest. Ein Nutzer, der einen geslugten russischen oder chinesischen Titel möchte, kann einen separaten Transliterationsschritt ausführen, bevor er den Text einfügt.

URL-Längenbegrenzungen, woher die 2.000-Zeichen-Regel kommt

RFC 3986 selbst spezifiziert keine Längenbegrenzung, die URI-Syntax ist unbegrenzt. Jede Grenze ist praktisch. Internet Explorer hat URLs historisch auf 2.083 Zeichen begrenzt (eine harte Grenze, eingebrannt in die Trident-Engine), woher die viel zitierte Faustregel der „2.000 Zeichen“ stammt. Chrome, Firefox, Safari und modernes Edge unterstützen URLs bis etwa 64.000 bis 100.000+ Zeichen in der Adressleiste. Apaches LimitRequestLine hat als Default 8.190 Bytes für die gesamte Request-Zeile; nginxs large_client_header_buffers hat als Default 8 KB; IIS hat als Default 4.096 Bytes für die URL und 2.048 für den Query-String. RFC 9110 (HTTP/1.1, 2022) empfiehlt in §4.1, dass ein Server „ought to be capable of handling URIs of length 8.000 octets or longer“, scheut sich aber, eine Obergrenze vorzuschreiben. Für Slugs zählt, dass sie konventionell kurz sind (drei bis sieben Wörter, dreißig bis sechzig Zeichen) für SEO und Teilbarkeit. Googles John Mueller hat in mehreren Webmaster Hangouts gesagt, dass die URL-Länge selbst kein Ranking-Signal ist, lange URLs jedoch in Suchergebnis-Snippets abgeschnitten werden, die Klickrate schädigen und in Social Shares unprofessionell wirken können. Die meisten Slug-Generatoren legen aus diesem Grund eine Maximal-Länge-Option offen; dieser hier ist standardmäßig unbegrenzt und lässt dich eine Grenze setzen.

Stop-Word-Entfernung: dicht vs grammatisch

Viele Slugify-Bibliotheken bieten optionale Stop-Word-Entfernung, verbreitete kurze Wörter (a, an, the, of, is, and, or, to, in, for, on) verwerfen, bevor der Slug zusammengesetzt wird. Die Begründung ist, dass sie kein SEO-Signal hinzufügen und die URL aufpolstern. So wird „The Best Way to Make a Cup of Tea“ zu best-way-make-cup-tea (5 Tokens, 24 Zeichen) statt the-best-way-to-make-a-cup-of-tea (10 Tokens, 35 Zeichen). Der Trade-off: kürzer und dichter, aber gelegentliches Grammatik-Zusammenfallen (how-to-be-good auf how-good reduziert verliert Bedeutung) und das Risiko, Wörter zu entfernen, die tatsächlich Absicht tragen (art-of-war auf art-war reduziert). WordPress entfernt Stop-Words standardmäßig nicht (es ist ein Opt-in-Plugin-Verhalten) und die meisten modernen Slug-Generatoren lassen es standardmäßig aus und legen es als Checkbox offen. Yoast SEO für WordPress markiert einen Slug, der Stop-Words enthält, als kleine Empfehlung statt als Fehler. Dieser Generator entfernt Stop-Words nicht automatisch, mit der Begründung, dass der Herausgeber die Absicht des Titels besser kennt als eine statische Wortliste. Wenn du sie weghaben willst, editiere die Ausgabe direkt.

Slug-Kollisionen: was CMSe tun, wenn zwei Beiträge denselben Titel teilen

Wenn zwei Beiträge denselben Slug auto-generieren, „My Post“ und „My-Post!“ erzeugen beide my-post: muss das System den Konflikt lösen. Die häufigsten Strategien: ein numerisches Suffix (my-post-2, my-post-3) (vorhersagbar, kollidiert nie, aber das Suffix trägt keinen semantischen Unterschied; ein Datumspräfix (2026-04-27/my-post)) funktioniert gut für Blog-Inhalte und ist der Default in Jekyll, Hugo und den meisten News-Sites; ein Autoren-Suffix (my-post-jane) (verwendet von Medium und Multi-Author-Blogs; ein zufälliges Hash-Suffix (my-post-a3f9)) verwendet von Stack Overflow, Notion und Shortlinking-Systemen, das menschliche Lesbarkeit gegen garantierte Eindeutigkeit tauscht; oder manuelles Editieren beim Veröffentlichen, redaktionell sauber, aber selten der Default, weil es den Fluss unterbricht. Die pragmatische Wahl für die meisten CMSe ist das numerische Suffix mit manuellem Editieren als Notausstieg. Datumspräfixierte Permalinks sind beliebt für zeitlich verankerte Inhalte, bei denen das Datum bedeutsame Information ist.

SEO-Auswirkung: der Slug als kleines, aber sichtbares Signal

Googles Ranking-Dokumentation listet die URL-Struktur als kleines Ranking-Signal, Seiteninhalt, Backlinks, Engagement-Signale und Frische tragen alle mehr Gewicht. Aber URL-Wörter tragen bei, und sie tragen sichtbar bei. Slug-Begriffe erscheinen in der URL-Zeile des SERP-Snippets unter dem Titel, was die Klickrate beeinflusst, auch wenn der Slug selbst nicht gerankt wird. Slug-Begriffe können in der SERP fett erscheinen, wenn sie zur Suchanfrage des Nutzers passen, zusätzliches visuelles Gewicht. Anker-Text aus internen und externen Links voreinst oft auf die URL, wenn kein Linktext angegeben ist, sodass ein semantischer Slug zum Linktext wird und seine Keywords durch eingehende Link-Equity trägt. A/B-Tests bei Herausgebern zeigen konsistent, dass beschreibende Slugs die CTR um einstellige Prozentpunkte über opaken IDs steigern. Backlinkos Ranking-Faktoren-Studie 2020 (1,18 Millionen SERPs analysiert) fand, dass kurze URLs in den Top-SERPs lange URLs leicht übertrafen.

Es gibt eine Ausnahme zur Intuition „mehr Keywords = besser“: Keyword-Stuffing. Das Exact-Match-Domain-(EMD)-Update vom September 2012 reduzierte spezifisch Credit für minderwertige Exact-Match-Domains und -Slugs (cheap-life-insurance.com/buy-cheap-life-insurance), und Google diskontiert seither Keyword-Stuffing in URLs. Die Schlussfolgerung 2026: Keyword-Präsenz im Slug hilft moderat; Keyword-Stuffing schadet. Der größte einzelne SEO-Gewinn von einem Slug ist, ihn nach der Veröffentlichung nicht zu ändern. Eingehende Links akkumulieren auf eine URL. Page Authority compoundet auf URL-Ebene. Eine 301-Weiterleitung bewahrt das meiste, aber nicht alle Link-Equity, und nur, wenn der Herausgeber die Weiterleitung tatsächlich einrichtet, viele tun das nicht. Der Berners-Lee-Rat „Cool URIs Don’t Change“ hat direkte SEO-Konsequenzen: jede Slug-Änderung, selbst mit Weiterleitung, kostet eine kleine Menge Autorität, die Zeit braucht, um sich zu erholen.

SEO-Best-Practices für Slugs

Häufige Fragen

Werden akzentuierte Zeichen unterstützt?

Ja. Der Generator nutzt die Unicode-Normalisierung (NFD), um Akzente zu entfernen. Beispielsweise bleibt „cafe" als „cafe", während „café" ebenfalls zu „cafe" wird. Damit entstehen saubere Slugs in reinem ASCII.

Soll ich Bindestriche oder Unterstriche verwenden?

Bindestriche werden für SEO empfohlen. Googles offizielle Anleitung bestätigt, dass Bindestriche in URLs als Worttrenner behandelt werden, Unterstriche jedoch nicht. „mein-artikel" wird also als zwei Wörter gelesen, „mein_artikel" hingegen als eines.

Was passiert mit Emoji und Symbolen?

Emoji sind nicht im Satz unreservierter URL-Zeichen, und NFD zerlegt sie nicht, sie haben kein lateinisches Äquivalent. Dieser Generator verwirft sie. Andere Tools percent-encodieren Emoji (verwandeln ein einzelnes Zeichen in eine lange Zeichenkette wie %F0%9F%94%A5), was technisch in modernen Browsern funktioniert, aber unleserliche URLs in Analytics, Social Shares und E-Mail-Vorschauen produziert. Die meisten Slug-Leitfäden empfehlen, Emoji ganz zu strippen; wenn du sie erhalten möchtest, percent-encodiere sie vor dem Slug-Schritt.

Wird das Russisch, Chinesisch oder Arabisch sluggen?

Nicht für sich genommen. NFD faltet nur lateinisch-schriftliche akzentuierte Zeichen; es kann nicht Kyrillisch, Griechisch, Arabisch, Hebräisch oder CJK-Schriften ins Lateinische transliterieren. Einen russischen oder chinesischen Titel in dieses Werkzeug einzufügen, verwirft diese Zeichen und produziert einen leeren oder fast leeren Slug. Der richtige Workflow ist, zuerst einen Transliterationsschritt auszuführen (Pythons unidecode, das npm-Paket transliteration für JavaScript, oder Wikipedias Romanisierungskonventionen) und das romanisierte Ergebnis hier einzufügen. Speziell für Japanisch verwende ein kana-bewusstes Werkzeug wie pykakasi: generische CJK-Transliteratoren wenden Mandarin-Pinyin an und produzieren Dong Jing für 東京 statt Tokyo.

Was, wenn ich einen Slug nach Veröffentlichung ändern muss?

Richte eine 301-Weiterleitung von der alten URL zur neuen ein, bevor du den Slug änderst. Ein 301 („Moved Permanently“) bewahrt das meiste der Link-Equity, die sich auf der alten URL angesammelt hat, und sagt Crawlern und Browsern, ihre Lesezeichen zu aktualisieren. Ohne Weiterleitung bricht jeder bestehende eingehende Link und du verlierst die Page Authority, die diese Links repräsentierten. Selbst mit Weiterleitung verlierst du eine kleine Menge Equity, die Wochen oder Monate braucht, um sich zu erholen. Die Berners-Lee-Maxime (cool URIs don’t change) ist teils ästhetisch, teils eine SEO-Wahrheit: jede Slug-Änderung kostet etwas, also lohnt es sich, den Slug beim ersten Mal richtig zu machen.

Gibt es eine empfohlene Slug-Länge?

Konvention sind drei bis sieben Wörter, etwa dreißig bis sechzig Zeichen. Lang genug, um beschreibend zu sein, kurz genug, dass Googles SERP-Snippet ihn nicht abschneidet und Menschen das Thema auf einen Blick erfassen können. Es gibt kein hartes technisches Maximum (RFC 3986 spezifiziert keines und moderne Browser handhaben URLs in den Zehntausenden Zeichen) aber Apache, nginx und IIS legen praktische Obergrenzen im Kilobyte-Bereich auf, und die alte „2.000-Zeichen“-Regel von Internet Explorer wird immer noch als sicheres plattformübergreifendes Limit zitiert. Die Option Maximallänge hier lässt dich die Ausgabe begrenzen; auf 0 gesetzt bedeutet unbegrenzt.

Werden meine Texte gespeichert oder irgendwohin gesendet?

Nein. Die Transformation läuft vollständig in deinem Browser über JavaScripts eingebaute String.prototype.normalize()-Methode (unterstützt seit Chrome 34, Firefox 31, Safari 10, etwa 2015). Nichts wird hochgeladen, keine API wird aufgerufen, keine Logs werden geschrieben. Du kannst das überprüfen, indem du den Network-Tab der DevTools deines Browsers öffnest, während du Slugs generierst, es gibt keine ausgehenden Anfragen. Die Seite ist sicher für Slugs aus unveröffentlichten Titeln, interner Dokumentation, Entwurfsbeiträgen oder jedem anderen Inhalt, den du nicht von deinem Gerät weglassen möchtest.

Verwandte Tools

URL-Encoder/Decoder

URLs und URI-Komponenten kodieren oder dekodieren.

Schreibweisen-Konverter

Text zwischen verschiedenen Schreibweisen umwandeln.

Wortzähler

Wörter, Zeichen und Lesezeit zählen.