php://input vs $_POST: Wann ich was in PHP nutze

Wenn ich in PHP Daten vom Request verarbeite, frage ich mich zuerst nicht: Was klingt moderner? Ich frage: Was ist die saubere Lösung für diesen konkreten Fall? Genau darum geht es bei php://input vs $_POST.

Beide Wege liefern mir Daten vom Client. Aber sie tun es nicht gleich. Und wenn ich das nicht sauber verstehe, baue ich schnell Bugs, die später Zeit kosten. Hier ist die einfache Version.

php://input vs $_POST: Der kurze Unterschied

$_POST ist ein PHP-Array. Es enthält Formulardaten, die mit application/x-www-form-urlencoded oder multipart/form-data gesendet wurden.

php://input ist ein Stream. Ich lese damit den Roh-Request-Body. Das ist nützlich für JSON, XML oder andere Payloads, die nicht automatisch in $_POST landen.

Einfach gesagt:

• $_POST = PHP hat die Daten schon für mich aufbereitet.
• php://input = Ich hole mir die rohen Daten selbst und verarbeite sie manuell.

Wann ich $_POST verwende

Ich nutze $_POST, wenn ein klassisches HTML-Formular abgeschickt wird. Das ist der Standardfall.

Typische Beispiele:

• Login-Formular
• Kontaktformular
• Checkout-Formular
• Backend-Formulare mit Dateiuploads

Warum? Weil PHP diese Daten direkt für mich parst. Ich muss nichts extra lesen oder dekodieren. Das spart mir Code und reduziert Fehler.

Vorteil: einfach, schnell, direkt nutzbar.

Nachteil: funktioniert nicht für jeden Request-Typ gleich gut.

Wann ich php://input verwende

Ich verwende php://input, wenn ich den rohen Request-Body brauche. Das ist besonders wichtig bei APIs.

Typische Fälle:

• JSON-Requests von Frontend-Apps
• Webhook-Calls von Drittanbietern
• REST-API-Endpunkte
• XML oder andere eigene Payloads

Wenn ich zum Beispiel mit JavaScript per fetch() JSON sende, landet das oft nicht in $_POST. Dann lese ich den Body mit php://input und dekodiere ihn selbst.

Beispiel:

$rawBody = file_get_contents('php://input');
$data = json_decode($rawBody, true);

Vorteil: flexibel für APIs und moderne Datenformate.

Nachteil: ich muss selbst parsen und validieren.

php://input vs $_POST: Die wichtigsten Unterschiede in der Praxis

Hier ist die Entscheidung in der echten Welt:

• Formular mit Input-Feldern: ich nehme $_POST.
• JSON vom Frontend: ich nehme php://input.
• Dateiupload: ich nutze $_FILES zusammen mit $_POST.
• Webhook mit Raw Body: ich nutze php://input.

Das ist kein Stil-Thema. Das ist ein Struktur-Thema. Wenn ich das Request-Format kenne, weiß ich sofort, welchen Weg ich nehme.

Warum $_POST manchmal leer ist

Das ist ein klassischer Fehler. Viele denken: Ich sende Daten, also muss $_POST gefüllt sein. Stimmt nicht.

$_POST wird nur automatisch befüllt, wenn der Content-Type passt. Bei JSON passiert das oft nicht.

Wenn ich also per fetch() so sende:

fetch('/api.php', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ name: 'Max' })
});

dann ist $_POST häufig leer. Der richtige Weg ist dann:

$rawBody = file_get_contents('php://input');
$data = json_decode($rawBody, true);

Das ist kein Bug in PHP. Das ist einfach das erwartete Verhalten.

Was ich bei php://input beachten muss

Ich behandle php://input nie blind als vertrauenswürdige Datenquelle. Egal ob JSON, XML oder irgendetwas anderes: Ich validiere immer.

Meine Regel ist simpel:

• Erst lesen.
• Dann prüfen.
• Dann verarbeiten.

Praktisch heißt das:

• JSON mit json_decode() parsen
• Fehler mit json_last_error() prüfen
• Pflichtfelder validieren
• Typen absichern
• Daten gegen Missbrauch schützen

Wenn ich das nicht mache, baue ich unsaubere APIs. Und unsaubere APIs kosten später mehr als saubere Arbeit am Anfang.

Wichtiger Punkt: php://input ist nicht dasselbe wie $_POST

Das klingt banal, aber genau hier passieren viele Fehler. php://input ist der rohe Body. $_POST ist bereits ein Array mit parsten Formulardaten.

Ich kann nicht erwarten, dass PHP mir JSON automatisch in $_POST legt. Und ich sollte auch nicht den Roh-Body lesen, wenn ein normales Formular schon sauber in $_POST verfügbar ist.

Mein Ziel ist immer dasselbe:

• weniger unnötiger Code
• weniger Parsing-Fehler
• bessere Lesbarkeit
• klare Trennung zwischen Formularen und APIs

Beispiele für die richtige Entscheidung

Fall 1: Kontaktformular
Ich nutze $_POST['email'] und $_POST['message']. Fertig.

Fall 2: SPA sendet JSON
Ich lese php://input, decode das JSON und arbeite dann mit dem Array weiter.

Fall 3: Payment-Webhook
Ich lese den Raw Body mit php://input, weil Signaturen oft genau auf dem unveränderten Inhalt basieren.

Fall 4: Datei-Upload
Ich nehme $_FILES für die Datei und $_POST für die restlichen Felder.

Meine Entscheidungsregel für php://input vs $_POST

Ich mache es so:

• HTML-Formular? Dann $_POST.
• JSON, XML oder Raw Body? Dann php://input.
• Upload? Dann $_FILES plus $_POST.
• Unklarer Request? Dann Content-Type prüfen und nicht raten.

Das spart mir Zeit und macht den Code robuster.

Hilfreiche offizielle Ressourcen

Wenn du tiefer einsteigen willst, nutze diese echten Dokumentationen:

• PHP Manual: $_POST
• PHP Manual: php:// wrapper
• PHP Manual: file_get_contents()
• PHP Manual: json_decode()

Fazit zu php://input vs $_POST

Ich denke bei php://input vs $_POST nicht in Technik-Nerd-Sprache. Ich denke in Use Cases. Formulare gehen über $_POST. Rohdaten, JSON und APIs gehen über php://input. So bleibt mein Code klar, wartbar und schnell zu verstehen.

Wenn ich diese Regel beachte, baue ich weniger Fehler ein und arbeite schneller. Genau das will ich. Und genau dafür ist php://input vs $_POST wichtig.