Generador de comandos cURL — Pide HTTP sin adivinar flags
Generador de comandos curl
Autenticación
Cabeceras
Cuerpo de la petición
curl \ -H 'Accept: application/json' \ 'https://api.example.com/v1/items?page=2'
El comando se ensambla en tu navegador y nunca se envía a ninguna parte. Los valores que contienen espacios o metacarácteres del shell se entrecomillan con comillas simples para que el comando se ejecute de forma segura tal cual; una comilla literal dentro de un valor se escapa al estilo POSIX.
Qué es
curl —client URL— es el programa de línea de comandos que transfiere datos hacia y desde un servidor usando sintaxis de URL. Viene incluido en macOS, forma parte de la instalación base de Git para Windows y está presente en prácticamente cualquier runner de CI, imagen de contenedor o shell remota que vayas a abrir. Nació en 1998 para descargar páginas web desde la terminal y se convirtió en el cliente HTTP universal: HTTP/1.1 y HTTP/2, HTTPS, proxies, cookies, redirecciones, además de FTP y SFTP. Todo comando cURL se lee igual, porque cada flag corresponde a una parte de la petición: - El flag de método. -X seguido de un verbo fija el método HTTP. En GET, el valor por defecto de curl, el flag puede omitirse por completo: un curl seguido de una URL ya hace un GET, y lo mismo ocurre con HEAD. Para POST, PUT, PATCH, DELETE y OPTIONS el flag es lo que le dice al servidor qué estás haciendo. - Los flags de cabecera. Cada -H 'Nombre: valor' añade una cabecera HTTP. Accept indica qué formato de respuesta quieres, Content-Type describe el cuerpo que envías y cualquier otro nombre se transmite tal cual. Los nombres de cabecera no distinguen mayúsculas en el protocolo. - Los flags de autenticación. -u 'usuario:contraseña' realiza autenticación Basic: curl codifica en base64 la pareja y la mete en una cabecera Authorization.
No existe un flag específico para Bearer; ese token se envía con -H 'Authorization: Bearer ...'. La diferencia conviene entenderla porque -u es solo una abreviatura de una cabecera concreta, no un segundo sistema de credenciales: escribir a mano esa misma cabecera Authorization produce una petición idéntica byte a byte. - Los flags de datos. -d, --data y --data-raw adjuntan un cuerpo, y --data-urlencode codifica en porcentajes una única pareja nombre=valor. Hay un comportamiento que sorprende: al añadir cualquier flag de datos, curl cambia el método a POST salvo que tú indiques -X explícitamente, así que un PUT con cuerpo puede acabar creando un recurso en lugar de actualizarlo. Este generador hace visible esa regla: si eliges un cuerpo mientras el método sigue en GET, aparece un -X POST por su cuenta. - La URL. Va al final, sin comillas si es limpia y con comillas si lleva query string. Las comillas son donde mueren casi todos los comandos escritos a mano. El shell interpreta el espacio, &, |, ;, $, >, *, ?, los paréntesis, la comilla simple y la doble como sintaxis, no como datos. Una URL pegada como https://api.example.com/buscar?q=a&b=2 se corta en el &: curl pide /buscar?q=a y el shell intenta ejecutar el token b=2, produciendo un error de comando no encontrado que no tiene relación con el servicio. El mismo destino aguarda a cualquier cuerpo JSON, porque los espacios entre llaves lo parten en varios argumentos. Envolver el valor en comillas simples le dice al shell que lo pase todo de forma literal.
Las comillas simples son el envoltorio más seguro porque nada dentro se interpreta: ni el signo dólar, ni una comilla acento grave, ni una segunda comilla. El único problema es un valor que contiene él mismo una comilla simple, que no puede escaparse dentro de comillas simples. POSIX lo resuelve cerrando la comilla, insertando una comilla escapada con barra invertida y abriendo la comilla de nuevo, que es exactamente lo que emite esta herramienta cuando encuentra un apóstrofo en una cabecera o en una contraseña. Un concepto más importa cuando el comando se ejecuta sin supervisión: la idempotencia. GET, HEAD, PUT y DELETE son idempotentes por definición, es decir, repetir la petición deja el servidor en el mismo estado que enviarla una vez, así que un reintento de red es inofensivo. POST no lo es: un POST reintentado puede crear dos registros o cobrar dos veces. Por eso curl reintenta por defecto solo métodos idempotentes, lo que explica que --retry sea seguro en scripts que mezclan verbos. Por último, cómo leer la salida. Por defecto curl dibuja una barra de progreso en la salida de error con el porcentaje, los bytes descargados y totales, la velocidad actual y el tiempo estimado restante; desaparece en cuanto canalizas o rediriges la salida, y --silent la elimina por completo. -v imprime la conversación completa, con < marcando lo que curl envía y > lo que recibe: la línea de petición, cada cabecera enviada, la línea de estado de la respuesta y cada cabecera recibida. -i conserva las cabeceras de respuesta en el cuerpo en lugar de descartarlas, y --fail hace que curl termine con código distinto de cero ante un 4xx o 5xx, que es justo lo que quieres en un script.
Cómo usar
- Elige en el desplegable Method el verbo que espera tu endpoint: GET, POST, PUT, PATCH, DELETE, HEAD u OPTIONS. El comando de abajo se actualiza solo y omite -X en GET y HEAD.
- Pega la URL completa en el campo URL, incluyendo el esquema y cualquier query string, por ejemplo https://api.example.com/v1/items?page=2.
- En Authentication pulsa None, Basic o Bearer. Basic revela los campos Username y Password y genera -u; Bearer muestra un único campo de token y construye la cabecera Authorization por ti.
- Trabaja en la sección Headers: marca la casilla de cada fila para incluirla o dejarla fuera, rellena los campos Header name y Header value, pulsa el × para borrar una fila innecesaria o usa + Add header para crear otra.
- Selecciona el tipo de cuerpo en Request body: No body, JSON, Form fields o Raw text. JSON y Form fields añaden el Content-Type correspondiente, salvo que ya hayas escrito tú una cabecera Content-Type.
- Con JSON activo, marca Pretty-print para que el cuerpo se vuelva a serializar con sangrado, o déjalo sin marcar para conservar exactamente lo que escribiste. Form fields convierte cada línea nombre=valor en un flag --data-urlencode independiente.
- Lee el comando montado en el bloque Command y pulsa Copy para llevar la versión de una sola línea al portapapeles. El montaje ocurre en tu navegador, así que las credenciales del comando no se transmiten a ninguna parte.
Ejemplos
Entrada: GET https://api.example.com/v1/items?page=2 con cabecera Accept: application/json
Proceso:
GET es el método por defecto de curl así que se omite -X, la cabecera sale con -H y la URL conserva el query stringResultado: curl \
-H 'Accept: application/json' \
https://api.example.com/v1/items?page=2
Entrada: POST https://api.example.com/v1/items con cuerpo JSON {"name":"example","active":true} y token Bearer
Proceso:
El cuerpo JSON genera -X POST y Content-Type, el token se convierte en cabecera Authorization y la carga útil va entre comillas simplesResultado: curl \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer eyJhbGciOi...' \
--data-raw '{
"name": "example",
"active": true
}' \
https://api.example.com/v1/items
Entrada: POST https://api.example.com/login con Form fields name=ada&password=secret y auth Basic ada:hunter2
Proceso:
La autenticación Basic se convierte en -u, cada campo del formulario en su propio flag --data-urlencode y se añade el Content-Type urlencodedResultado: 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
Entrada: DELETE https://api.example.com/v1/items/42 con cabecera personalizada X-Request-Id: 8f14e45f
Proceso:
DELETE no lleva cuerpo así que -X DELETE es explícito, la cabecera personalizada va entre comillas y no se añade nada que el usuario no pidieraResultado: curl \
-X DELETE \
-H 'X-Request-Id: 8f14e45f' \
https://api.example.com/v1/items/42
Búsquedas Relacionadas
La gente también busca: generador de comandos curl, crear comando curl, comando curl online, curl con cabeceras, curl autenticacion basica, curl token bearer.
generador de comandos curlcrear comando curlcomando curl onlinecurl con cabecerascurl autenticacion basicacurl token bearercurl enviar jsoncurl datos de formulariosintaxis de curlprobar api con curlcliente http de linea de comandoscomillas en el shellherramienta de desarrollogenerador de peticiones httpcurl con autenticaciondepurar api restejemplo de curltool online gratis
Preguntas Frecuentes
¿Por qué el generador no escribe -X en las peticiones GET?
Porque un curl sin flags seguido de una URL ya hace un GET, así que el flag sería ruido puro. El mismo razonamiento vale para HEAD, que se usa para pedir solo cabeceras. Para POST, PUT, PATCH, DELETE y OPTIONS el método debe declararse, así que el flag sí se emite. Si algún día hablas con un endpoint que exige un verbo poco habitual, añádelo tú como fila de cabecera personalizada y aparecerá igualmente en el comando.
¿Debería usar -u o escribir la cabecera Authorization a mano?
Producen la misma petición. -u 'usuario:clave' es una abreviatura que codifica la pareja en base64 y envía la cabecera Authorization: Basic, ahorrándote esa codificación. Escribir la cabecera a mano solo tiene ventaja cuando el esquema de credenciales es propio, cuando el token contiene caracteres que preferirías leer de un archivo en vez de escribirlos en la línea de comandos, o cuando la contraseña incluye dos puntos, porque todo lo que va tras el primero se toma como contraseña.
¿Por qué mi cuerpo JSON necesita comillas simples alrededor?
Porque el shell analiza la línea antes de que curl reciba los argumentos, y un cuerpo JSON sin comillas está lleno de espacios, llaves, comillas y dos puntos que el shell interpreta como sintaxis. Sin las comillas, la carga útil se parte en varios argumentos y curl muestra un confuso error de datos ausentes. Dentro de comillas simples cada carácter pasa literalmente, incluidas las comillas dobles que el JSON necesita. Esta herramienta cita cualquier valor que no sea seguro alfanuméricamente, de modo que el comando se puede pegar tal cual.
¿El generador añade la cabecera Content-Type por mí?
Sí, pero solo si tú no has indicado ninguna. Elegir el cuerpo JSON añade Content-Type: application/json, y elegir Form fields añade Content-Type: application/x-www-form-urlencoded. Si ya existe una fila Content-Type en la lista, se salta la suya para no enviar la cabecera dos veces con valores contradictorios. Enviar JSON sin Content-Type es una causa habitual de errores 400: el servidor asume codificación de formulario y no consigue interpretar tu carga útil.
¿Es seguro pegar aquí un token Bearer o una contraseña reales?
Sí en lo que se refiere a la envío de datos. El comando lo genera JavaScript que se ejecuta en la pestaña de tu navegador, así que la URL, las credenciales y las cabeceras nunca salen de tu máquina ni llegan a nuestros servidores. No se almacena nada, no se registran logs y al cerrar la pestaña los valores desaparecen. Aun así conviene el sentido habitual: un token escrito en cualquier página puede quedar expuesto por una extensión del navegador, y un comando pegado en la terminal acabará en tu historial, así que usa valores de ejemplo en cualquier documentación que compartas.
¿Cómo envío datos de formulario en lugar de JSON?
Elige Form fields en la sección Request body y escribe una pareja nombre=valor por línea; también funciona todo en la misma línea separado por ampersands, porque la herramienta lo divide. Cada pareja se convierte en su propio flag --data-urlencode 'nombre=valor' y el Content-Type se fija en application/x-www-form-urlencoded. Usa codificación porcentual en lugar de ampersands crudos en los valores que contengan caracteres reservados, o el servidor recibirá el campo truncado.
¿Por qué añadir un cuerpo cambia mi método a POST?
Ese es el comportamiento de curl: cuando adjuntas datos con -d o --data-raw sin indicar método, curl asume POST. El generador lo reproduce con honestidad en lugar de esconderlo, así que si el desplegable sigue en GET y añades un cuerpo verás aparecer -X POST. Cambia antes el método en el desplegable al que realmente necesitas, o corrígelo después, para que la petición no convierta sin querer una actualización en una creación.