Häufige Regex-Muster aus der Praxis: E-Mail, URL, Datum, IP und mehr

Bestimmte Eingaben tauchen in fast jedem Projekt auf: E-Mail-Adressen, Datumsangaben, Postleitzahlen oder Telefonnummern. Für all diese gibt es eingespielte reguläre Ausdrücke, die man nicht jedes Mal neu erfinden muss. Wichtig ist aber zu verstehen, was diese Muster leisten und vor allem, wo ihre Grenze verläuft. Denn ein Format zu erkennen ist nicht dasselbe wie zu prüfen, ob etwas tatsächlich existiert.

Warum sich fertige Muster lohnen

Es klingt verlockend, jedes Muster selbst zu schreiben, doch bei verbreiteten Eingaben ist das selten sinnvoll. Eine E-Mail-Adresse oder eine IP-Adresse hat tausende Entwickler vor uns beschäftigt, und die typischen Fallstricke sind längst bekannt. Ein bewährtes Muster zu übernehmen spart nicht nur Zeit, es vermeidet auch die Fehler, die man beim ersten eigenen Versuch fast zwangsläufig macht, etwa das Vergessen der Anker am Anfang und Ende oder das versehentliche Zulassen von Leerzeichen.

Gleichzeitig sollte man ein übernommenes Muster nie blind einsetzen. Jedes Projekt hat eigene Anforderungen: Mal sind führende Nullen erlaubt, mal nicht, mal soll ein Feld optional sein. Deshalb gehört jedes kopierte Muster im Regex-Tester gegen die eigenen Beispiele geprüft, bevor es in den Code wandert. So verbindet man die Erfahrung anderer mit den konkreten Regeln des eigenen Falls.

Die wichtigste Lektion vorweg

Bevor es zu den Mustern geht, eine Unterscheidung, die in der Praxis ständig unterschätzt wird. Eine Regex prüft Syntax, also die Form einer Zeichenkette. Sie prüft nicht Semantik, also ob der Wert in der Wirklichkeit gültig ist. Ein Muster kann bestätigen, dass eine Postleitzahl aus fünf Ziffern besteht, aber nicht, dass diese Postleitzahl wirklich vergeben ist. Es kann ein Datum auf das richtige Format prüfen, aber nicht wissen, ob dieser Tag im Kalender existiert.

Die Validierung eines Formats ist nicht die Validierung der Existenz. Wer das verwechselt, baut sich ein falsches Sicherheitsgefühl ein.

Diese eine Einsicht erspart viele Bugs. Wer sie verinnerlicht, setzt Regex dort ein, wo sie stark ist, und ergänzt sie dort, wo eine echte Prüfung nötig ist. Grundlagen zum Aufbau von Mustern liefert der Ratgeber Was sind reguläre Ausdrücke?.

E-Mail-Adresse

Das klassische Beispiel. Ein praxistaugliches Muster für eine E-Mail sieht so aus:

^[^@\s]+@[^@\s]+\.[^@\s]+$

Übersetzt heißt das: ein oder mehrere Zeichen, die kein At-Zeichen und kein Leerzeichen sind, dann ein At-Zeichen, dann wieder solche Zeichen, ein Punkt und noch ein Block. Das fängt grobe Fehler wie fehlendes At-Zeichen oder fehlende Domain ab. Die Grenze: Es akzeptiert auch Adressen, deren Domain gar nicht existiert, und lehnt umgekehrt manche seltene, aber gültige Adresse ab. Mehr Kontext bietet die Anleitung für E-Mail-Muster.

URL und Telefonnummer

Für eine URL prüft man typischerweise das Schema, also http oder https, gefolgt von Doppelpunkt, zwei Schrägstrichen und einem Hostteil:

^https?:\/\/[^\s/$.?#].[^\s]*$

Das deckt die meisten Web-Adressen ab, garantiert aber nicht, dass die Seite erreichbar ist. Bei Telefonnummern ist die Sache noch heikler, weil Formate international stark variieren. Ein bewusst lockeres Muster erlaubt Ziffern, Leerzeichen, das Plus für die Ländervorwahl und Bindestriche:

^\+?[\d\s\-()]{6,}$

Hier gilt besonders: lieber zu locker als zu streng, sonst werden gültige Nummern abgelehnt.

Datum, Postleitzahl, IP und Hex-Farbe

Bei diesen vier Typen wird die Grenze zwischen Format und Gültigkeit besonders sichtbar. Ein deutsches Datum im Format Tag Punkt Monat Punkt Jahr lässt sich so beschreiben:

^\d{2}\.\d{2}\.\d{4}$

Das Muster akzeptiert klaglos auch den 31.02.2026, weil es nur zählt, nicht rechnet. Die deutsche Postleitzahl ist schlicht eine fünfstellige Ziffernfolge, eine IPv4-Adresse besteht aus vier durch Punkte getrennten Zahlengruppen, und eine Hex-Farbe beginnt mit einer Raute gefolgt von drei oder sechs Hexadezimalstellen. Praktische Datumsmuster mit ihren Tücken behandelt die Anleitung für Datums-Muster.

Tabelle: Muster, Zweck und Grenze

Die folgende Übersicht ordnet die gängigen Muster nach ihrem Zweck und benennt ehrlich, wo sie aufhören zu helfen.

Muster	Zweck	Grenze
E-Mail	Grobform mit At-Zeichen und Punkt prüfen	Sagt nichts über Existenz oder RFC-Vollständigkeit
URL	Schema und Hostteil erkennen	Prüft nicht, ob die Seite erreichbar ist
Telefon	Ziffern, Plus und Trenner zulassen	Internationale Formate kaum vollständig abbildbar
Datum	Format Tag Monat Jahr prüfen	Akzeptiert unmögliche Tage wie den 31. Februar
Postleitzahl	Fünf Ziffern in Deutschland prüfen	Prüft nicht, ob die Postleitzahl vergeben ist
IP-Adresse	Vier Zahlengruppen erkennen	Lässt ungültige Oktette über 255 durch
Hex-Farbe	Raute plus drei oder sechs Hexstellen	Prüft Syntax, nicht den gewünschten Farbeindruck

Muster nicht nur prüfen, sondern auch auslesen

Bislang ging es um das Erkennen, also die Frage, ob eine Eingabe einem Format entspricht. Reguläre Ausdrücke können aber mehr: Mit Gruppen lassen sich Teile aus einem Treffer herausziehen. Setzt man einen Abschnitt eines Musters in runde Klammern, wird dieser Teil als eigene Capturing Group erfasst. So kann man aus einem Datum im Format Tag Monat Jahr die drei Bestandteile einzeln entnehmen, statt nur ein Ja oder Nein zu bekommen.

Das ist besonders praktisch beim Verarbeiten von Logdateien, beim Zerlegen von URLs oder beim Umstellen von Datumsformaten. Eine benannte Gruppe macht das Ergebnis dabei lesbarer, weil man den Teil später über seinen Namen anspricht statt über eine Nummer. Im Regex-Tester sieht man die erkannten Gruppen direkt neben dem Treffer, was das Entwickeln solcher Extraktions-Muster deutlich beschleunigt.

Streng oder locker: die richtige Balance

Eine der häufigsten Fragen lautet, wie streng ein Muster sein soll. Die kurze Antwort: so locker wie möglich, so streng wie nötig. Ein zu strenges Muster lehnt gültige Eingaben ab und frustriert Nutzer, etwa wenn eine korrekte, aber ungewöhnliche E-Mail-Adresse zurückgewiesen wird. Ein zu lockeres Muster lässt dagegen Unsinn durch. Die Kunst liegt darin, den häufigsten Fehlerfall abzudecken, ohne den seltenen Sonderfall zu blockieren.

Hilfreich ist es, vom Zweck her zu denken. Will ich nur grobe Tippfehler abfangen, bevor die Daten weiterverarbeitet werden, reicht ein lockeres Muster. Geht es um sicherheitskritische Eingaben, prüft man besser im Code zusätzlich zur Regex. Diese Abwägung lässt sich am besten treffen, indem man das Muster mit einer Liste echter und absichtlich falscher Beispiele gegentestet und beobachtet, was es durchlässt.

Wann Regex die falsche Wahl ist

So nützlich Muster sind, es gibt klare Fälle, in denen man die Finger davon lassen sollte. Der Klassiker ist die vollständige E-Mail-Validierung nach Standard: Hier ist eine Bestätigungsmail die einzig verlässliche Methode. Der zweite Klassiker ist das Parsen von HTML oder XML. Diese Sprachen sind verschachtelt und kontextabhängig, reguläre Ausdrücke sind das von ihrer Natur her nicht. Für HTML gehört ein echter Parser zum Einsatz.

Auch wenn ein Muster nur leicht zu kompliziert wirkt, lohnt der Schritt zurück. Manchmal sind zwei einfache Prüfungen im Code klarer und wartbarer als ein einzelner überladener Ausdruck. Typische Fehlerquellen und wie man sie umgeht, beschreibt der Ratgeber Häufige Regex-Fehler vermeiden. Und wer dieselben Muster in mehreren Sprachen einsetzen will, findet im Beitrag Regex in verschiedenen Programmiersprachen die nötigen Unterschiede.

So nutzt du die Muster richtig

Am schnellsten kommt man ans Ziel, indem man ein Muster nimmt, es im Regex-Tester gegen echte Beispiele und gegen bewusst falsche Eingaben laufen lässt und dabei beobachtet, was es durchlässt. Genau diese Gegenprobe mit absichtlich ungültigen Werten deckt die Grenzen eines Musters auf. Wer ein Format-Muster mit einer echten Prüfung kombiniert, etwa eine E-Mail-Regex mit einer Bestätigungsmail, bekommt das Beste aus beiden Welten: schnelle Fehlererkennung im Browser und echte Gewissheit dort, wo es darauf ankommt.