<form>

Zuletzt aktualisiert am 30. Januar 2026

Kontaktformulare, Login-Seiten, Suchfelder, Newsletter-Anmeldungen: überall im Web begegnen dir Formulare. Das <form>-Element erstellt ein interaktives Formular und ist der Container für alle Eingabeelemente wie Textfelder, Checkboxen und Buttons. Wenn ein Nutzer auf “Absenden” klickt, verpackt das Formular die eingegebenen Daten und schickt sie an den Server. Auf dieser Seite lernst du, wie dieser Ablauf funktioniert, was der Unterschied zwischen GET und POST ist und worauf du bei Datei-Uploads achten musst.

Grundlagen

Stell dir ein Formular wie einen Briefumschlag vor: Du steckst Informationen hinein (<input>, <textarea>), schreibst eine Adresse drauf (action) und wählst, wie der Brief verschickt wird (method). Wenn der Nutzer auf den Absende-Button klickt, nimmt der Browser alle Felder mit einem name-Attribut, packt ihre Werte zusammen und schickt sie an die URL, die du in action angegeben hast.

• <form> ist ein Block-Element und der Container für alle Formularelemente
• Das action-Attribut definiert, wohin die Daten gesendet werden (eine URL auf deinem Server)
• Das method-Attribut definiert wie die Daten gesendet werden: per GET oder POST
• Formulare können nicht verschachtelt werden: ein <form> innerhalb eines anderen <form> ist ungültiges HTML

GET vs. POST

Der Unterschied ist wichtig und lässt sich gut mit einer Analogie merken:

• GET ist wie eine Postkarte: Die Daten stehen offen in der URL (z.B. /suche?q=html). Jeder kann sie lesen, und du kannst die URL als Lesezeichen speichern oder teilen. Verwende GET für Suchen, Filter und alles, was keine sensiblen Daten enthält.

• POST ist wie ein verschlossener Briefumschlag: Die Daten werden im Body des HTTP-Requests verschickt und sind nicht in der URL sichtbar. Verwende POST für Logins, Registrierungen, Kontaktformulare und alles mit persönlichen oder sensiblen Daten.

Syntax

<form action="/suche" method="get">
  <label for="q">Suche:</label>
  <input type="text" id="q" name="q" placeholder="Suchbegriff...">
  <button type="submit">Suchen</button>
</form>

Attribute

enctype-Werte

Das enctype-Attribut bestimmt, wie die Formulardaten beim Absenden verpackt werden. Du brauchst in den allermeisten Fällen nur die ersten zwei Optionen:

• application/x-www-form-urlencoded (Standard): Daten werden als URL-encoded String gesendet (z.B. name=Max&email=max@example.com). Für die meisten Formulare genau richtig
• multipart/form-data (Pflicht bei Datei-Uploads): Wenn dein Formular ein <input type="file"> enthält, musst du diesen Encoding-Typ setzen. Sonst bekommt der Server nur den Dateinamen, aber nicht die Datei selbst
• text/plain: Sendet die Daten als unformatierten Text. Nur zum Debuggen nützlich, nicht für den Produktiveinsatz

Beispiele

Kontaktformular

Ein typisches Kontaktformular mit Name, E-Mail und Nachricht. Hier verwendest du method="post", weil persönliche Daten übermittelt werden:

<form action="/kontakt" method="post">
  <div>
    <label for="name">Name:</label>
    <input type="text" id="name" name="name" required>
  </div>
  <div>
    <label for="email">E-Mail:</label>
    <input type="email" id="email" name="email" required>
  </div>
  <div>
    <label for="msg">Nachricht:</label>
    <textarea id="msg" name="nachricht" rows="4"></textarea>
  </div>
  <button type="submit">Absenden</button>
</form>

Datei-Upload

Wenn dein Formular einen Datei-Upload enthält, brauchst du unbedingt enctype="multipart/form-data". Ohne dieses Attribut kommt beim Server nur der Dateiname an, aber nicht die eigentliche Datei:

<form action="/upload" method="post" enctype="multipart/form-data">
  <label for="datei">Datei auswählen:</label>
  <input type="file" id="datei" name="datei" accept="image/*">
  <button type="submit">Hochladen</button>
</form>

Barrierefreiheit

Formulare sind für viele Nutzer eine Herausforderung, besonders für Menschen, die auf Screenreader oder Tastaturnavigation angewiesen sind. Ein paar Grundregeln machen den Unterschied zwischen einem frustrierenden und einem nutzbaren Formular.

Labels sind Pflicht. Jedes Eingabefeld braucht ein sichtbares <label>, das über for mit der id des Feldes verknüpft ist. Placeholder-Text ist kein Ersatz für Labels: er verschwindet, sobald der Nutzer tippt, und wird von vielen Screenreadern nicht zuverlässig vorgelesen.

Gruppiere zusammengehörige Felder mit <fieldset> und <legend>. Bei Checkbox-Gruppen oder Radio-Buttons ist das besonders wichtig. Ohne <fieldset> hört ein Screenreader-Nutzer nur “Anfänger, Radio-Button”, aber nicht, dass es um die Frage “Erfahrungslevel” geht. Mit <legend> wird der Kontext klar.

Fehlermeldungen müssen zugänglich sein. Wenn ein Feld ungültig ist, reicht es nicht, den Rahmen rot zu färben. Verknüpfe die Fehlermeldung über aria-describedby mit dem jeweiligen Feld und setze aria-invalid="true". So liest der Screenreader beim Fokussieren des Feldes automatisch die Fehlermeldung vor.

Tastaturnavigation testen. Jedes Formular sollte komplett mit der Tastatur bedienbar sein: Tab zum nächsten Feld, Shift+Tab zurück, Enter zum Absenden. Achte darauf, dass die Tab-Reihenfolge logisch ist und kein Feld übersprungen wird. Benutzerdefinierte Widgets (Custom Dropdowns, Toggle-Switches) brauchen oft zusätzliche role- und aria-Attribute, um mit der Tastatur bedienbar zu sein.

aria-label für Formulare ohne sichtbare Überschrift. Wenn dein Formular keine sichtbare Überschrift hat (z.B. ein Suchfeld im Header), gib dem <form>-Element ein aria-label, damit Screenreader-Nutzer wissen, worum es geht: <form aria-label="Seitensuche">.

Häufige Fehler

• enctype vergessen bei Datei-Uploads: Das ist einer der häufigsten Fehler. Ohne enctype="multipart/form-data" sendet der Browser bei einem Datei-Upload nur den Dateinamen als Text, nicht die eigentliche Datei. Der Server bekommt dann einen String wie "foto.jpg" statt der Bilddaten.

• Formulare verschachteln: <form> innerhalb von <form> ist ungültiges HTML. Der Browser ignoriert das innere Formular, und die Absende-Logik funktioniert nicht wie erwartet. Wenn du mehrere unabhängige Absende-Aktionen brauchst, verwende separate Formulare nebeneinander.

• Kein name-Attribut auf Eingabefeldern: Das name-Attribut ist entscheidend: es ist der Schlüssel, unter dem der Server die Daten empfängt. Ein <input> ohne name wird beim Absenden komplett ignoriert. Der Server bekommt die Eingabe dann einfach nicht.

• GET für sensible Daten: Wenn du method="get" für ein Login-Formular verwendest, steht das Passwort in der URL (z.B. /login?password=geheim). Das erscheint im Browser-Verlauf, in Server-Logs und kann von Dritten eingesehen werden. Verwende für sensible Daten immer method="post".

Browser-Kompatibilität

Das form-Element wird von allen Browsern vollständig unterstützt. Die HTML5-Validierungsattribute (wie required, pattern, novalidate) funktionieren ebenfalls in allen modernen Browsern zuverlässig.

Email-Kompatibilität

Formulare werden von den meisten Email-Clients aus Sicherheitsgründen nicht unterstützt. Interaktive Elemente werden in der Regel entfernt oder ignoriert.

Verwandte Elemente