Validador de OpenAPI JSON

Pega el contenido de tu archivo openapi.json o swagger.json y obtén una comprobación estructural en segundos. El validador confirma que el JSON se parsea, que el campo de versión está presente, que info tiene un título y una versión, y que existe paths. Después avisa de nombres de ruta extraños y de claves de operación desconocidas.

Cómo validar un archivo JSON de OpenAPI

  1. 1

    Copia el archivo

    Abre tu `openapi.json` y copia el documento completo, desde la llave de apertura hasta la de cierre.

  2. 2

    Pégalo en el cuadro

    Pégalo en el campo del documento OpenAPI / Swagger. No hace falta quitar espacios ni dar formato.

  3. 3

    Ejecuta la comprobación

    Continúa al paso de resultados para lanzar la validación.

  4. 4

    Corrige y repite

    Edita el archivo para cada error, pégalo otra vez y repite hasta que el informe no muestre errores.

Errores comunes de JSON que hacen fallar la comprobación

JSON es más estricto que YAML, así que la mayoría de los fallos en un archivo editado a mano vienen de la sintaxis y no del diseño de la API. Las causas habituales son una coma sobrante tras la última propiedad, comillas simples en lugar de dobles, un comentario (JSON no los admite) o una llave de cierre que falta tras un objeto paths largo. Un archivo roto suele terminar con el mensaje “No se pudo analizar como JSON ni como YAML”, o con errores de campos ausentes porque no se leyó nada utilizable.

Si solo ves un error de análisis, busca primero el fallo de sintaxis. Las comprobaciones estructurales se ejecutan cuando el documento se lee como objeto.

Un ejemplo práctico

Toma este documento pequeño:

{
  "openapi": "3.0.3",
  "info": { "title": "Orders API" },
  "paths": {
    "orders": { "get": { "summary": "List orders" } }
  }
}

Se parsea, y el campo openapi y el objeto paths están presentes. El informe seguiría mostrando:

Hallazgo Tipo Motivo
info.version es obligatorio. Error info tiene título pero no version
La ruta ‘orders’ debería empezar por ‘/’. Aviso La clave de ruta no tiene barra inicial

Como hay un error, el documento no se considera válido. Añade "version": "1.0.0" a info y renombra la clave a /orders. Una segunda ejecución elimina los dos hallazgos.

Qué significa un resultado correcto y qué no

Un informe limpio significa que la estructura básica está bien. No sigue los enlaces $ref, no comprueba los esquemas ni confirma que cada operación tenga respuestas. Tómalo como una puerta rápida antes de confirmar el archivo y luego ejecuta un linter completo para las reglas más profundas.

Un flujo práctico para especificaciones JSON

Guarda la especificación en control de versiones y pégala aquí antes de cada commit que toque paths. Como la comprobación es rápida, funciona como paso de cordura tras combinar cambios de varias personas, cuando es más probable que haya claves duplicadas o una llave mal colocada. Si tu JSON lo genera un script de compilación, pega la salida generada y no la plantilla, para probar lo que realmente recibirán los lectores. Cuando el informe esté limpio, comparte el archivo o pásalo a un generador de documentación con más confianza en que la estructura de nivel superior es sólida.

Preguntas frecuentes

No. Los espacios en blanco y la indentación no importan. Pega el archivo tal cual.

El JSON estándar no admite una coma después del último elemento de un objeto o de un array, así que el documento no se puede leer como JSON. Quita la coma y vuelve a ejecutar la comprobación.

Sí. La comprobación de versión acepta un campo openapi o un campo swagger, así que los JSON de Swagger 2.0 y de OpenAPI 3.x pasan por la misma comprobación estructural.

No. Los hallazgos aparecen como mensajes, como un campo que falta o un nombre de ruta, sin números de línea. Busca en tu archivo la clave que nombra el mensaje.

Herramientas relacionadas

Herramienta disponible en otros idiomas

Guías y casos de uso