01
Ein erreichbares Testziel wählen
Das Beispiel füllt lediglich eine öffentliche URL. Von einer HTTPS-Seite kann ein HTTP-Ziel als gemischter Inhalt blockiert werden; CORS muss das Lesen der Antwort gestatten.
HTTP und Anfrage-Debugging
HTTP-Anfragen online testennur nach Ihrem Klick
Methode, URL, Header und Textkörper prüfen, dann bewusst senden. Die Ziel-API muss CORS für diese Herkunft erlauben.
HTTP-Anfragen online testen
Anfrage
Anfrage-Header
Anfragetext
Diese Methode sendet keinen Anfragetext.
Erst nach Ihrem Klick geht die Anfrage direkt vom Browser an das Ziel. Keine produktiven Geheimnisse eingeben.
Antwort
Noch keine Antwort.
Optionen
Anfangs aus. In diesem Tab bleiben nur Methode, URL-Pfad ohne Query-Werte, Zeit und Status; Header und Textkörper nicht. URL-Pfade können Kennungen enthalten; bei sensiblen Pfaden den Verlauf ausgeschaltet lassen.
Grenzen: 50 Header, 1 MiB Textkörper, 8 MiB lesbare Antwort. CORS und verbotene Browser-Header gelten.
Anfragecode
Die Codevorschau sendet nichts. Query-Werte und sensible Header sind Platzhalter; vor dem Teilen auch den Body prüfen.
HTTP(S)-URL eingeben und bewusst senden.
Wer eine API im Browser prüft, möchte wissen, was nach einem konkreten Aufruf sichtbar wird. Mit HTTP-Anfragen online testen bauen Sie genau eine Anfrage mit URL, Headern und gegebenenfalls JSON auf; beim Tippen wird nichts gesendet.
Der Online HTTP-Client zeigt die Grenzen des Browsers offen. Ein HTTP-Anfrage-Tester im Terminal kann Antworten lesen, die CORS einer Webseite verwehrt. REST-APIs testen heißt hier daher auch: den Unterschied zwischen einer HTTP-Antwort und einem nicht lesbaren Netzwerkfehler erkennen.
Warum HTTP-Anfragen online testen?
Direkter Browseraufruf ohne allgemeinen Proxy und ohne versteckte Wiederholung.
Nur bewusst an das Ziel senden
HTTP-Anfragen online testen löst erst nach einem Klick eine Fetch-Anfrage aus. Ist die Antwort für diese Herkunft freigegeben, sehen Sie echten Status, sichtbare Header und Inhalt; sonst erfindet das Werkzeug keinen Statuscode.
Verlauf ohne Header und Textkörper
Der Verlauf ist anfangs aus. Eingeschaltet merkt er sich nur Methode, URL-Pfad ohne Abfragewerte, Zeit und Status in diesem Tab. Codebeispiele ersetzen sensible Header und Abfragewerte durch Platzhalter.
Vor dem Senden prüfen, danach richtig deuten
02
Body und Zeitlimit festlegen
POST, PUT, PATCH und DELETE erlauben Rohtext oder JSON. Im JSON-Modus wird die Syntax geprüft und Content-Type nur ergänzt, wenn er fehlt. Strg/Cmd+Eingabe löst ebenfalls ausdrücklich das Senden aus.
03
Antwort und Fehler auseinanderhalten
Auch 4xx und 5xx können lesbare Antworten sein. Bei CORS- oder Netzwerkfehler fehlt ein sichtbarer Status. Änderungen sperren den Export alter Ergebnisse; Abbrechen macht eine serverseitige Aktion nicht rückgängig.
Eine Anfrage aufbauen und auswerten
Sieben Methoden
GET, POST, PUT, PATCH, DELETE, HEAD und OPTIONS stehen bereit. Zulässige eigene Header und Textkörper für passende Methoden decken einfache API-Tests ab.
Sichtbare Antwortdaten
Status, Laufzeit, freigegebene Header und Textinhalt erscheinen zusammen. JSON wird nur für die Anzeige eingerückt, Binärdaten erhalten Typ und Bytezahl.
Antwort unverändert speichern
Lesbare Antworten bis 8 MiB lassen sich vollständig herunterladen. Die Datei enthält die empfangenen Bytes, nicht die hübsch formatierte JSON-Ansicht.
cURL und Fetch vorab ansehen
Die Codevorschau benötigt keinen Netzwerkaufruf. Sensible Headerwerte und sämtliche Query-Werte werden in den Beispielen durch Platzhalter ersetzt.
Grenzen von Fetch und CORS
- Ein CORS-Fehler beweist keinen fehlenden Versand
- Eine einfache Anfrage kann den Server erreichen, obwohl der Browser die Antwort verbirgt. Scheitert eine Voranfrage, wird der eigentliche Aufruf nicht ausgeführt. Allgemeine Fehler trennen CORS und Netzwerk nicht sicher.
- Kein universeller Server-Proxy
- HTTP-Anfragen online testen verwendet Fetch direkt. Es gibt keinen HeyUtils-Proxy zum Umgehen von CORS; ein solcher Dienst bräuchte gesonderten SSRF-Schutz, Begrenzung und bereinigte Logs.
- Verbotene Header werden abgewiesen
- Cookie, Host, Origin, Content-Length und Sec-* dürfen Seitenskripte nicht setzen. Das Formular meldet diese Namen vor dem Senden, statt ihren Versand vorzutäuschen.
- Keine Cookie-Verwaltung und Wiederholung
- Browser-Zugangsdaten werden weggelassen. Ein fehlgeschlagener POST wird nie automatisch wiederholt; auch ein abgebrochener lokaler Wartevorgang kann den Server nicht zurücksetzen.
- Begrenzte Datenmenge und Speicherzeit
- Textkörper sind auf 1 MiB, vollständig lesbare Antworten auf 8 MiB begrenzt. Der optionale Verlauf hält nur eine bereinigte Zusammenfassung im aktuellen Tab und wird beim Ausschalten gelöscht.
Fragen zu HTTP-Anfragen online testen
Wie teste ich eine HTTP-API?
Geben Sie eine absolute HTTP(S)-URL ein und klicken Sie Senden. Das Beispiel und jede Eingabeänderung bleiben lokal, bis Sie den Aufruf ausdrücklich starten.
Warum erhalte ich einen CORS-Fehler?
Oft verweigert der Zielserver dieser Browser-Herkunft die Leseberechtigung. Ein einfacher Aufruf kann trotzdem angekommen sein; prüfen Sie die CORS-Einstellungen und gegebenenfalls Serverlogs.
Kann ich POST-Anfragen mit JSON-Body senden?
Ja. Wählen Sie POST und JSON, geben Sie einen gültigen Textkörper ein. Content-Type wird nur ergänzt, wenn kein eigener Wert vorhanden ist.
Welche HTTP-Methoden werden unterstützt?
GET, POST, PUT, PATCH, DELETE, HEAD und OPTIONS. Für GET, HEAD und OPTIONS erlaubt dieses Werkzeug keinen Body; das entspricht dem unterstützten Browsermodell.
Kann ich APIs mit Authentifizierung testen?
Sie können Authorization oder X-API-Key für ein Testziel eintragen. Das Werkzeug sendet diese Werte erst nach Ihrem Klick und speichert sie nicht im optionalen Verlauf.
Ein Feld wird falsch gelesen?
Jetzt HTTP-Anfragen online testen
Mit HTTP-Anfragen online testen prüfen Sie eine CORS-fähige Test-API, lesen den tatsächlich freigegebenen Inhalt und speichern die Antwort vor dem nächsten Versuch.