ErrorBase
Referencia técnica independienteSitio oficial
  • Software y sistemas
  • Servicio HTTP

400

HTTP 400 Bad Request: el servidor rechaza una petición malformada

Verificada con fuentes2 fuentesRevisada 4 oct 2026
¿Viene un técnico? Mira los 2 pasos que debe enseñarte

Nivel de riesgo

Seguro

Puedes actuar sin peligro siguiendo las comprobaciones seguras.

Urgencia

Media — atiéndelo hoy

Respuesta rápida

HTTP 400 indica que el servidor considera que tu petición tiene un error de formato y no la procesa. Lee el mensaje que muestre la página, revisa lo que escribiste o el enlace usado y no repitas lo mismo: fallará igual. Si persiste, avisa al administrador.

Seguridad primero

Antes de continuar

  • Recargar o reenviar sin cambiar nada no resuelve un 400: el servidor rechazará la misma petición con el mismo error.

Puedes hacerlo con seguridad

  • Explicación en la página de error
  • Mismo paso desde la portada
  • Petición capturada frente a una válida

Deja estas tareas a un profesional cualificado

  • No intentes esta tarea profesional: Validación con mensajes claros en el servidor
  • No intentes esta tarea profesional: Revisión de registros del servidor

Lo que un técnico debe poder justificar

Viene un técnico

Estos son los pasos que tiene que hacer y enseñarte. Márcalos mientras trabaja: si se salta pasos, no aceptes el cambio de pieza.

No son instrucciones para que abras o manipules el equipo. Son las comprobaciones que deben sostener una conclusión técnica.

  1. Validación con mensajes claros en el servidor

    Qué haceEl desarrollador hace que cada 400 devuelva en el cuerpo qué campo o regla falló, en lugar de un texto genérico.

    Te tiene que enseñaruna respuesta 400 de prueba con el campo señalado.

    Por escritoel formato de error adoptado y las rutas cubiertas.

  2. Revisión de registros del servidor

    Qué haceEl administrador busca la petición en los registros del servidor web y de los intermediarios para ver qué equipo emitió el 400 y por qué regla.

    Te tiene que enseñarla línea del registro con la hora y la regla aplicada.

    Por escritola causa encontrada y el cambio hecho.

Antes de aceptar una pieza o reparación

Aún no ha demostrado nada. No aceptes un cambio de pieza solo por el código.

Sigue estos pasos

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

  1. Explicación en la página de error

    Sin herramientas especiales

    Quién:
    tú, como visitante.
    Cómo:
    lee entera la página o el aviso que acompaña al 400; RFC 9110 pide al servidor describir el error y al navegador mostrarlo.
    Resultado que importa:
    si el texto nombra un campo, un formato o un dato concreto.
    Si nombra un campo:
    confirma qué corregir; cambia ese dato y envía de nuevo una sola vez.
    Si solo dice Bad Request sin detalle:
    indica que el diagnóstico necesita al responsable de la web.
    Evidencia a conservar:
    captura del mensaje completo con la hora.

    Evidencia: RFC 9110 section 15.5 - Client Error 4xx · 400 Bad Request - HTTP | MDN

  2. Mismo paso desde la portada

    Sin herramientas especiales

    Quién:
    tú, como visitante.
    Cómo:
    en vez de usar el enlace guardado o pegado, entra por la página principal y llega navegando al mismo formulario o sección.
    Resultado que importa:
    si el 400 depende del enlace o del contenido enviado.
    Si navegando funciona:
    indica que el enlace estaba dañado; sustituye el marcador.
    Si vuelve el 400 al enviar los mismos datos:
    descarta el enlace y apunta al formato de lo que envías.
    Evidencia a conservar:
    la URL que fallaba y la que funcionó, sin datos personales.

    Evidencia: RFC 9110 section 15.5.1 - 400 Bad Request · 400 Bad Request - HTTP | MDN

  3. Petición capturada frente a una válida

    Sin herramientas especiales

    Quién:
    el desarrollador de la web o de la aplicación cliente.
    Cómo:
    captura la petición fallida con las herramientas de red y compárala con una que el servidor acepte: método, cabeceras, tipo de contenido y cuerpo.
    Resultado que importa:
    la primera diferencia que el servidor considera inválida.
    Si el cuerpo no valida contra el formato esperado:
    confirma un error del cliente; corrige la serialización.
    Si la petición es idéntica a una aceptada:
    indica una regla del servidor o de un intermediario que hay que revisar en sus registros.
    Evidencia a conservar:
    ambas peticiones guardadas con credenciales ocultas y el mensaje de error.

    Evidencia: RFC 9110 section 15.5.1 - 400 Bad Request · 400 Bad Request - HTTP | MDN

Situación no resuelta

Si el error persiste, no sigas probando por tu cuenta. Mira qué tiene que hacer y enseñarte el técnico.

Dónde se aplica este código

Un código solo tiene significado dentro del producto y la versión correctos.

Ámbito principal

Sistema
Software y sistemas
Marca
HTTP
Tipo de producto
Servicio HTTP

Variantes conocidas del código

  • 400 Bad Request
  • 400 Richiesta non valida
  • 400 Solicitud incorrecta
  • 400 Ungültige Anfrage
  • code erreur 400
  • HTTP 400
  • HTTP status 400
  • status code 400

Qué significa

RFC 9110 define 400 (Bad Request): el servidor no puede o no quiere procesar la petición por algo que percibe como error del cliente, por ejemplo sintaxis mal formada, un mensaje con delimitación inválida o un enrutado engañoso. Es la respuesta genérica de la familia 4xx y el estándar pide al servidor explicar el error en el cuerpo. MDN añade que repetir la misma petición sin cambios dará el mismo 400, como un JSON inválido enviado a una API. El código no identifica qué parte de la petición falló si el servidor no lo explica.

Advertencias y condiciones de parada

  • Seguroverificada con fuente

    Recargar o reenviar sin cambiar nada no resuelve un 400: el servidor rechazará la misma petición con el mismo error.

    Evidencia: 400 Bad Request - HTTP | MDN

Síntomas y causas

Causas probables · en orden

  • Datos con formato inválidoFrecuente

    El cuerpo enviado no respeta el formato esperado, como el JSON con saltos de línea sin escapar del ejemplo de MDN. Se confirma cuando el mensaje de la respuesta señala el campo o la sintaxis.

    Evidencia: RFC 9110 section 15.5.1 - 400 Bad Request · 400 Bad Request - HTTP | MDN

  • Enlace o dirección alteradosPosible

    Una URL copiada a medias o con caracteres extraños puede llegar al servidor como petición mal formada. Encaja si el error aparece solo con ese enlace y no navegando desde la portada.

    Evidencia: RFC 9110 section 15.5.1 - 400 Bad Request

  • Cliente que envía cabeceras o encuadre incorrectosPosible

    Una aplicación o extensión que construye mal la petición, con un mensaje mal delimitado o datos de enrutado engañosos, cae en las causas que cita RFC 9110. Lo separa el desarrollador comparando la petición capturada con otra válida.

    Evidencia: RFC 9110 section 15.5.1 - 400 Bad Request

Técnico virtual

¿Sigue apareciendo 400 tras comprobarlo?

Responde unas preguntas para acotar la causa probable y la siguiente acción segura. Es una orientación - nunca sustituye a un profesional.

Iniciar diagnóstico

Fuentes y referencias técnicas

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Fuentes: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsrevisado 2026-10-04 · verificado

¿Te ha resultado útil esta ficha?