cURL-Befehls-Generator — HTTP-Anfragen ohne Rätselraten bauen
curl-Befehls-Generator
Authentifizierung
Header
Request-Body
curl \ -H 'Accept: application/json' \ 'https://api.example.com/v1/items?page=2'
Der Befehl wird in Ihrem Browser zusammengestellt und nirgendwohin gesendet. Werte, die Leerzeichen oder Shell-Metazeichen enthalten, werden in einfache Anführungszeichen gesetzt, damit der Befehl so, wie er dasteht, sicher läuft; ein wörtliches Anführungszeichen innerhalb eines Werts wird nach POSIX-Art maskiert.
Was ist
curl — client URL — ist das Kommandozeilenprogramm, das Daten mit URL-Syntax an einen Server sendet und von ihm empfängt. Es ist in macOS enthalten, Teil der Basisinstallation von Git für Windows und in praktisch jedem CI-Runner, Container-Image und entfernten Shell vorhanden. 1998 entstand es, um Webseiten im Terminal zu laden, und wurde zum universellen HTTP-Client: HTTP/1.1 und HTTP/2, HTTPS, Proxys, Cookies, Weiterleitungen sowie FTP und SFTP. Jeder cURL-Befehl liest sich gleich, weil jedes Flag genau einem Teil der Anfrage entspricht: - Das Methoden-Flag. -X gefolgt von einem Verb legt die HTTP-Methode fest. Bei GET, curls Standard, kann das Flag ganz entfallen: curl plus URL ist bereits ein GET, und für HEAD gilt dasselbe. Bei POST, PUT, PATCH, DELETE und OPTIONS teilt erst dieses Flag dem Server mit, was du vorhast. - Die Header-Flags. Jedes -H 'Name: Wert' fügt einen HTTP-Header hinzu. Accept sagt, welches Antwortformat du möchtest, Content-Type beschreibt den gesendeten Body, jeder andere Name wird unverändert durchgereicht. In der Bezeichnung sind Header-Namen nicht case-sensitiv. - Die Auth-Flags. -u 'Benutzer:Passwort' führt eine HTTP-Basic-Authentifizierung durch, wobei curl das Paar base64-kodiert und in einen Authorization-Header schreibt.
Für Bearer gibt es kein eigenes Flag; das Token wird mit -H 'Authorization: Bearer ...' gesendet. Dieser Unterschied lohnt sich zu verstehen, denn -u ist eine Abkürzung für genau einen Header und kein zweites Anmeldesystem — derselbe Authorization-Header von Hand geschrieben ergibt eine byteidentische Anfrage. - Die Daten-Flags. -d, --data und --data-raw hängen jeweils einen Body an, --data-urlencode kodiert ein einzelnes Paar name=wert als Prozentzeichenfolge. Ein Verhalten überrascht viele: Sobald du ein Daten-Flag hinzufügst, schaltet curl die Methode auf POST, sofern du nicht selbst -X setzt. Ein PUT mit Body kann daher unbemerkt ein neues Objekt anlegen, statt etwas zu ändern. Dieser Generator macht diese Regel sichtbar: Wählst du einen Body, während die Methode noch GET ist, erscheint von selbst ein -X POST. - Die URL. Sie steht ganz hinten, ohne Anführungszeichen, wenn sie schlicht ist, und quotiert, wenn sie einen Query-String trägt. An den Anführungszeichen sterben die meisten von Hand geschriebenen Befehle. Die Shell interpretiert Leerzeichen, &, |, ;, $, >, *, ?, Klammern sowie einfache und doppelte Anführungszeichen als Syntax und nicht als Daten. Eine als https://api.example.com/search?q=a&b=2 eingefügte URL wird am & abgeschnitten: curl fragt /search?q=a ab, und die Shell versucht anschließend, den Rest auszuführen, was ein command not found produziert, das mit dem Dienst nichts zu tun hat. Einem JSON-Body widerfährt dasselbe, weil die Leerzeichen innerhalb der geschweiften Klammern ihn in mehrere Argumente zerlegen.
Den Wert in einfache Anführungszeichen zu wickeln heißt für die Shell: alles wörtlich weitergeben. Einfache Anführungszeichen sind die sicherste Hülle, weil darin nichts interpretiert wird: kein Dollarzeichen, kein Backtick, kein zweites Anführungszeichen. Das einzige Problem ist ein Wert, der selbst ein einfaches Anführungszeichen enthält, denn innerhalb einfacher Anführungszeichen lässt sich keines escapen. POSIX löst das, indem das Anführungszeichen geschlossen, ein per Backslash escaped Anführungszeichen eingefügt und das Anführungszeichen wieder geöffnet wird — genau die Form, die dieses Werkzeug erzeugt, sobald es auf ein Apostroph in einem Header-Wert oder Passwort stößt. Ein weiterer Begriff zählt, sobald ein Befehl unbeaufsichtigt läuft: Idempotenz. GET, HEAD, PUT und DELETE sind per Definition idempotent, das heißt, dass das Wiederholen der Anfrage den Server in denselben Zustand bringt wie das einmalige Senden, ein erneuter Netzwerkversuch ist also folgenlos. POST ist das nicht: Ein wiederholter POST kann zwei Datensätze anlegen oder zweimal eine Karte belasten. Deshalb wiederholt curl standardmäßig nur idempotente Methoden, und deshalb ist --retry in Skripten mit gemischten Verben in der Regel unbedenklich. Zuletzt das Lesen der Ausgabe. Standardmäßig zeichnet curl einen Fortschrittsbalken auf stderr mit Prozent, geladenen und Gesamtbytes, aktueller Geschwindigkeit und geschätzter Restzeit. Sobald du die Ausgabe umleitest oder durch eine Pipe schickst, verschwindet er, und --silent unterdrückt ihn ganz. -v gibt das gesamte Gespräch aus, wobei < markiert, was curl sendet, und > markiert, was eingeht: Anfragezeile, alle gesendeten Header, die Statuszeile der Antwort und alle empfangenen Header. -i behält die Antwortheader im Ausgabe-Body, statt sie wegzuwerfen, und --fail lässt curl bei einem 4xx oder 5xx mit einem Exit-Code ungleich null enden — genau das Verhalten, das man in einem Skript braucht.
Wie zu verwenden
- Wähle im Dropdown Method das Verb, das dein Endpunkt erwartet: GET, POST, PUT, PATCH, DELETE, HEAD oder OPTIONS. Der Befehl unten schreibt sich dabei sofort mit und lässt -X bei GET und HEAD bewusst weg.
- Füge die vollständige URL in das URL-Feld ein, inklusive Schema und Query-String, zum Beispiel https://api.example.com/v1/items?page=2.
- Klicke unter Authentication auf None, Basic oder Bearer. Basic blendet die Felder Username und Password ein und erzeugt -u; Bearer zeigt ein einzelnes Token-Feld und baut den Authorization-Header für dich.
- Arbeite im Abschnitt Headers: Hake das Kästchen jeder Zeile an oder ab, fülle Header name und Header value aus, klicke auf ×, um eine unnötige Zeile zu löschen, oder auf + Add header für eine neue.
- Wähle unter Request body den Body-Typ: No body, JSON, Form fields oder Raw text. JSON und Form fields ergänzen den passenden Content-Type, sofern du nicht selbst schon einen Content-Type-Header angelegt hast.
- Aktiviere bei JSON die Option Pretty-print, damit der Body mit Einrück neu serialisiert wird, oder lass sie leer, damit exakt deine Eingabe erhalten bleibt. Form fields macht aus jeder Zeile name=wert ein eigenes --data-urlencode-Flag.
- Lies den fertigen Befehl im Block Command und drücke Copy, um die einzeilige Fassung in die Zwischenablage zu legen. Zusammengestellt wird im Browser, sodass Passwörter und Tokens im Befehl nirgendwohin gesendet werden.
Beispiele
Eingabe: GET https://api.example.com/v1/items?page=2 mit Header Accept: application/json
Prozess:
GET ist curls Standardmethode, daher entfällt -X; der Header wird mit -H ausgegeben und die URL behält ihren Query-StringErgebnis: curl \
-H 'Accept: application/json' \
https://api.example.com/v1/items?page=2
Eingabe: POST https://api.example.com/v1/items mit JSON-Body {"name":"example","active":true} und Bearer-Token
Prozess:
Der JSON-Body erzeugt -X POST und den Content-Type, das Token wird zum Authorization-Header und die Nutzlast steht in einfachen AnführungszeichenErgebnis: curl \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer eyJhbGciOi...' \
--data-raw '{
"name": "example",
"active": true
}' \
https://api.example.com/v1/items
Eingabe: POST https://api.example.com/login mit Form fields name=ada&password=secret und Basic-Auth ada:hunter2
Prozess:
Basic-Auth wird zu -u, jedes Formularfeld zu einem eigenen --data-urlencode-Flag, und der urlencoded-Content-Type wird ergänztErgebnis: curl \
-H 'Content-Type: application/x-www-form-urlencoded' \
-u 'ada:hunter2' \
--data-urlencode 'name=ada' \
--data-urlencode 'password=secret' \
https://api.example.com/login
Eingabe: DELETE https://api.example.com/v1/items/42 mit eigenem Header X-Request-Id: 8f14e45f
Prozess:
DELETE trägt keinen Body, daher steht -X DELETE ausdrücklich da, der eigene Header wird quotiert und nichts hinzugefügt, was nicht verlangt warErgebnis: curl \
-X DELETE \
-H 'X-Request-Id: 8f14e45f' \
https://api.example.com/v1/items/42
Verwandte Suchen
Leute suchen auch nach: curl befehl generator, curl befehl erstellen, curl befehl online, curl mit header, curl basic authentication, curl bearer token.
curl befehl generatorcurl befehl erstellencurl befehl onlinecurl mit headercurl basic authenticationcurl bearer tokencurl json sendencurl formular datencurl syntaxapi mit curl testenhttp client kommandozeileshell quoting lernenentwicklerwerkzeughttp anfrage bauencurl authentifizierungrest api debuggencurl beispiel befehlkostenloses online tool
Häufig gestellte Fragen
Warum lässt der Generator -X bei GET-Anfragen weg?
Weil curl ohne Flags gefolgt von einer URL bereits ein GET ausführt, das Flag wäre also reines Rauschen. Für HEAD gilt dasselbe, weil es nur Header anfordert. Bei POST, PUT, PATCH, DELETE und OPTIONS muss die Methode benannt werden, dort wird das Flag also ausgegeben. Wenn du eines Tages mit einem Endpunkt sprechen musst, der ein ungewöhnliches Verb verlangt, lege einfach selbst eine eigene Header-Zeile an, sie landet ebenfalls im Befehl.
Sollte ich -u verwenden oder den Authorization-Header selbst schreiben?
Beides ergibt dieselbe Anfrage. -u 'Benutzer:Passwort' ist eine Abkürzung, die das Paar base64-kodiert und einen Authorization: Basic-Header sendet, damit du dir diese Kodierung sparst. Selbst schreiben lohnt sich nur, wenn das Authentifizierungsschema ein eigenes ist, wenn der Token Zeichen enthält, die du lieber aus einer Datei liest statt auf die Kommandozeile zu tippen, oder wenn das Passwort selbst einen Doppelpunkt enthält, denn alles nach dem ersten wird als Passwort gelesen.
Warum braucht mein JSON-Body einfache Anführungszeichen?
Weil die Shell die Kommandozeile parst, bevor curl seine Argumente bekommt, und ein JSON-Body ohne Anführungszeichen voller Leerzeichen, geschweifter Klammern, Anführungszeichen und Doppelpunkte ist, die die Shell als Syntax versteht. Ohne Anführungszeichen zerfällt die Nutzlast in mehrere Argumente, und curl meldet einen verwirrenden Fehler über fehlende Daten. In einfachen Anführungszeichen kommt jedes Zeichen wörtlich an, auch die doppelten Anführungszeichen, die JSON selbst braucht. Dieses Werkzeug quotiert jeden Wert, der nicht rein alphanumerisch sicher ist, der Befehl läuft also unverändert so wie ausgegeben.
Fügt der Generator den Content-Type-Header selbst hinzu?
Ja, aber nur, wenn du selbst keinen angegeben hast. Wählst du den JSON-Body, kommt Content-Type: application/json hinzu, bei Form fields entsprechend Content-Type: application/x-www-form-urlencoded. Existiert in der Header-Liste schon eine Content-Type-Zeile, überspringt er seine eigene, damit derselbe Header nicht zweimal mit widersprüchlichen Werten gesendet wird. JSON ohne Content-Type zu schicken ist eine häufige Ursache für 400er-Fehler: Der Server nimmt Formular-Kodierung an und scheitert daran, deine Nutzlast zu lesen.
Ist es sicher, hier einen echten Bearer-Token oder ein echtes Passwort einzugeben?
Ja, was das Versenden angeht. Der Befehl wird von JavaScript in deinem Browser-Tab erzeugt, URL, Zugangsdaten und Header verlassen deinen Rechner also nie und erreichen unsere Server nicht. Nichts wird gespeichert, nichts protokolliert, und beim Schließen des Tabs verschwinden die Werte. Trotzdem gilt die übliche Vorsicht: Ein in irgendeine Webseite getippter Token kann durch eine Browsererweiterung offengelegt werden, und ein in die Shell eingefügter Befehl landet in deren Verlauf — verwende in gemeinsam genutzter Dokumentation also Platzhalter.
Wie sende ich Formulardaten statt JSON?
Wähle im Abschnitt Request body die Option Form fields und schreibe pro Zeile ein Paar name=wert; auch alles in einer Zeile durch & verbunden funktioniert, weil das Werkzeug es auftrennt. Jedes Paar wird zu einem eigenen --data-urlencode 'name=wert'-Flag, und der Content-Type wird auf application/x-www-form-urlencoded gesetzt. Verwende Prozentkodierung statt eines rohen & in Werten, die selbst reservierte Zeichen enthalten, sonst kommt beim Server ein abgeschnittenes Feld an.
Warum wird aus meiner Methode POST, sobald ich einen Body hinzufüge?
Das ist curls eigenes Verhalten: Hängst du mit -d oder --data-raw Daten an, ohne eine Methode zu nennen, nimmt curl POST an. Der Generator bildet das ehrlich ab, statt es zu verbergen, du siehst also ein -X POST erscheinen, wenn das Dropdown noch auf GET steht. Ändere zuerst im Dropdown die tatsächlich gemeinte Methode oder korrigiere sie hinterher, damit aus einer beabsichtigten Aktualisierung keine unbemerkte Neuanlage wird.