Extractor de rutas JSON

Cómo funciona

1. Pega tu JSON: introduce un objeto o un array JSON en el campo de entrada.
2. Introduce una expresión JSONPath: escribe una ruta como $.store.book[*].author o $.users[?(@.age > 18)] para seleccionar los datos que quieras.
3. Visualiza los resultados extraídos: los valores coincidentes aparecen al instante en el panel de salida. Copia el resultado o expórtalo.

¿Por qué usar el extractor JSONPath?

Cuando trabajas con respuestas de API complejas o JSON profundamente anidado, extraer valores específicos a mano es lento y propenso a errores. JSONPath es el lenguaje de consulta para JSON, similar a XPath para XML. Permite apuntar exactamente a los datos que necesitas mediante una expresión de ruta concisa, ya sea un valor anidado único, todos los elementos de un array o registros filtrados que coinciden con una condición. Esta herramienta hace la exploración JSONPath interactiva sin escribir código.

Funcionalidades

• Compatibilidad completa con JSONPath: notación de puntos, notación entre corchetes, comodines (*), descenso recursivo (..), filtros (?()) y slices de arrays.
• Evaluación en directo: los resultados se actualizan a medida que escribes tu expresión JSONPath.
• Salida formateada: los valores extraídos se muestran como JSON bien formateado.
• Coincidencias múltiples: devuelve todos los nodos coincidentes del documento JSON.
• Señalización de errores: mensajes claros cuando la expresión de ruta es inválida o no produce coincidencias.

Preguntas frecuentes

¿Qué es JSONPath?

JSONPath es un lenguaje de consulta para documentos JSON, análogo a XPath para XML. Una ruta como $.users[*].name selecciona el campo name de cada objeto en el array users. Se usa ampliamente para testing de API, transformación de datos y procesamiento JSON.

¿Cómo filtrar los elementos de un array por una condición?

Usa una expresión de filtro: $.items[?(@.price < 50)] devuelve todos los elementos cuyo precio es inferior a 50. El símbolo @ hace referencia al elemento en curso de evaluación.

¿Admite la búsqueda recursiva?

Sí. El operador .. efectúa una búsqueda recursiva a todos los niveles. Por ejemplo, $..name encuentra todas las claves name allá donde se encuentren en la estructura JSON, sea cual sea la profundidad del anidamiento.

De una entrada de blog a RFC 9535: el camino de 17 años hacia un estándar JSONPath

Stefan Gössner propuso JSONPath en una sola entrada de blog en febrero de 2007, adaptando la idea de XPath a JSON. Publicó una implementación JavaScript de referencia, esbozó la sintaxis (la raíz $, los operadores hijo punto y corchete, .. para descenso recursivo, * para comodín, [inicio:fin:paso] para corte de array, [?(...)] para expresiones de filtro) y el ecosistema más amplio lo siguió. Las implementaciones proliferaron: jsonpath para JavaScript, JsonPath para Java, jq (Stephen Dolan, 2012) que es adyacente a JSONPath pero su propia cosa, jsonpath-ng para Python, JMESPath (AWS, 2014) como rival más estricto. El problema: cada implementación derivó. Sintaxis de filtro, semántica de recursión, coincidencia de regex, identificadores de raíz, todos sutilmente diferentes entre bibliotecas. Un estudio comparativo de 2023 por Carsten Bormann et al. probó 41 implementaciones JSONPath distintas contra la misma entrada y obtuvo 41 conjuntos de resultados diferentes para la misma expresión. El Grupo de Trabajo JSONPath del IETF se reunió en 2020 para arreglar esto. RFC 9535 «JSONPath: Query Expressions for JSON» fue publicado en febrero de 2024, convirtiéndose en el primer estándar formal para JSONPath, 17 años después del post original de Gössner. RFC 9535 codifica la sintaxis, define un formato de salida normalizado, requiere normalización Unicode para comparaciones de cadenas, y añade una suite de pruebas de conformidad.

Hoja de trucos de sintaxis JSONPath

Los siete operadores que cubren la mayoría de consultas del mundo real:

• $ raíz. Cada ruta comienza aquí. $ por sí mismo devuelve todo el documento.
• .nombre hijo por nombre. $.store.book selecciona el campo book dentro de store. Nombres con espacios o caracteres especiales necesitan notación de corchete: $['book title'].
• [0] índice de array. $.book[0] primer elemento. $.book[-1] último elemento (añadido en RFC 9535).
• [inicio:fin:paso] corte de array. Estilo Python: $.book[1:3] elementos 1 y 2, $.book[::2] cada otro elemento. paso puede ser negativo para invertir.
• * comodín. $.book[*].title el título de cada libro. También funciona como comodín de propiedad: $.store.* todos los hijos inmediatos de store.
• .. descenso recursivo. $..title encuentra cada campo title a cualquier profundidad. Potente pero lento en documentos grandes.
• [?(...)] expresión de filtro. $.book[?(@.price < 10)] todos los libros con precio inferior a 10. @ significa «el elemento actual». RFC 9535 lo llama ? y estandariza los operadores de comparación == != < <= > >= más booleanos && ||. El modo rápido de este visor no evalúa expresiones de filtro, usa una biblioteca como jsonpath-plus si las necesitas.

Donde realmente recurres a JSONPath

• Filtrado de salida kubectl. kubectl get pods -o jsonpath='{.items[*].metadata.name}' viene en Kubernetes y es un consumidor JSONPath de uso diario. La variante Kubernetes elimina el $ inicial y tiene algunas particularidades dignas de notar si vives en ese ecosistema.
• Pruebas API con Postman o Insomnia. Las aserciones de prueba como pm.expect(jsonData.items[0].status).to.eql('active') generalmente se expresan como JSONPath bajo el capó.
• Paneles Grafana / observabilidad. Los paneles de fuente de datos JSON consultan métricas usando JSONPath; los recolectores OpenTelemetry usan una sintaxis similar a JSONPath para extraer atributos de span.
• Extracción CLI rápida. Empareja esta herramienta con curl | jq para exploración API en vivo: prototipa la ruta en el visor, luego traduce a sintaxis jq para scripts shell. (jq usa notación de punto pero no es estrictamente JSONPath.)
• ETL e ingeniería de datos. Los mapeos Airflow XCom, archivos seed dbt, y la extracción de columnas JSON SQL usan expresiones similares a JSONPath para llegar a payloads anidados.
• Inspección de tokens. Profundiza en un JWT decodificado: $.payload.iss para el emisor, $..roles[*] para cada rol otorgado en cualquier lugar del árbol de reclamaciones.
• Diseño de manejador webhook. Antes de escribir el código del manejador, pega un payload webhook real y prototipa las rutas que extraen los campos que importan a tu sistema. Ahorra un viaje de ida y vuelta con el servicio aguas arriba.

Errores que muerden

• Deriva de implementación. Una ruta que funciona en una biblioteca puede producir resultados diferentes, o ningún resultado, en otra. Antes de RFC 9535 nada estaba estandarizado. Ahora busca «conforme RFC 9535» en los docs de tu biblioteca (la suite de pruebas IETF se publica con la RFC).
• Comillas de filtro. $.book[?(@.title=="Foo")] requiere comillas dobles dentro del filtro en RFC 9535; muchas bibliotecas más antiguas también aceptan comillas simples 'Foo'. Mezclarlas es una causa común de «error de sintaxis» en producción.
• El descenso recursivo es codicioso. $..* devuelve cada valor en el documento, incluyendo objetos y arrays anidados mismos, no solo hojas. En documentos grandes esto puede tomar segundos. Estrecha primero la ruta, luego desciende.
• Claves enteras vs cadena. JSON solo tiene claves de cadena, incluso cuando se ven numéricas. $.users.123 y $.users[123] significan cosas diferentes en algunas bibliotecas: la primera busca una propiedad literalmente llamada "123", la segunda puede interpretarse como el índice de array 123.
• Cortes negativos. $.book[-1:] significa «el último elemento» en RFC 9535 y la mayoría de implementaciones, pero antes de 2024 algunas bibliotecas trataban los índices negativos como errores. Si apuntas a parseadores antiguos, usa índices absolutos.
• Olvidar $. Una ruta sin $ inicial es inválida en RFC 9535. Algunas implementaciones aceptan .store.book como abreviatura, otras la rechazan. Siempre prefija con $.
• Rendimiento. El descenso recursivo .. en un documento de 10 MB puede ser O(n) por coincidencia. Para columnas de almacén de datos o bucles calientes, pre-extrae una vez con $.., cachea el resultado, luego camina el array cacheado. Nunca ejecutes un JSONPath complejo en cada solicitud.

JSONPath vs jq vs JMESPath vs JSON Pointer

• JSONPath (RFC 9535). Mejor para consultas ad-hoc y archivos de configuración. La sintaxis es familiar de XPath, el estándar es fresco, múltiples bibliotecas de lenguaje lo soportan.
• jq. Un lenguaje completo de transformación de datos, no solo una consulta de ruta. Añade map/filter/reduce, funciones de cadena, matemáticas, formato. Mejor cuando necesitas remodelar datos, no solo extraerlos. Tiene su propia sintaxis con notación de punto pero diverge de JSONPath a nivel de filtros.
• JMESPath. Una alternativa de 2014 usada por AWS CLI (aws ec2 describe-instances --query "..."). Más estricto y funcional que JSONPath, tiene una gramática real desde el primer día, soporta proyecciones y operadores pipe. Menos común fuera del ecosistema de Amazon.
• JSON Pointer (RFC 6901). Un estándar de 2013 para direccionar un valor único: /store/book/0/title. No puede hacer comodines, filtros, o recursión. Usado por JSON Patch (RFC 6902), JSON Schema $ref, y la API de patch de Kubernetes. Elige esto cuando necesitas apuntamiento exacto, no consulta.

Más preguntas frecuentes

¿JSONPath es lo mismo que XPath?

Inspirado por él, no idéntico. XPath fue finalizado por W3C en 1999 para XML, JSONPath fue esbozado por Gössner en 2007 para llevar la misma idea a JSON. Las mayores diferencias: JSONPath usa . y [] en lugar de /, JSONPath no tiene concepto de espacios de nombres XML o atributos, JSONPath se estandarizó mucho después (2024 vs 1999), así que durante años fue una sintaxis de facto con muchas implementaciones incompatibles.

¿Por qué el mismo JSONPath da resultados diferentes en diferentes herramientas?

Porque JSONPath no se estandarizó hasta RFC 9535 (febrero de 2024). Antes de eso, cada implementación tomaba sus propias decisiones sobre sintaxis de filtro, soporte de regex, identificadores de raíz, reglas de escape, y casos límite (arrays vacíos, claves faltantes, coerción de tipo en filtros). Un estudio del grupo de trabajo IETF de 2023 probó 41 implementaciones en la misma entrada y obtuvo 41 conjuntos de resultados diferentes. RFC 9535 arregla esto para bibliotecas nuevas y actualizadas; las bibliotecas más antiguas divergirán hasta que migren. Siempre verifica si tu biblioteca afirma «conformidad RFC 9535».

¿Puedo modificar el JSON con JSONPath, o solo leer?

RFC 9535 define JSONPath estrictamente como un lenguaje de consulta: devuelve valores de un documento, no muta. Para modificar JSON, usa JSON Patch (RFC 6902), que usa rutas JSON Pointer y operaciones add/remove/replace/copy/move/test. Algunas bibliotecas combinan ambos (p. ej. jsonpath-plus en JavaScript tiene una extensión de mutación apply()) pero eso no es JSONPath estándar.

¿JSONPath soporta expresiones regulares en filtros?

RFC 9535 añadió dos funciones regex: match(node, regex) coincide con toda la cadena, search(node, regex) coincide con cualquier subcadena. Ejemplo: $.book[?(match(@.isbn, "^978-"))]. El sabor regex es I-Regexp (RFC 9485, un perfil de regex de XML Schema), no PCRE o regex JavaScript. Las bibliotecas más antiguas usaban el sabor regex de su lenguaje anfitrión, lo que hace las consultas regex especialmente no portables.

¿Mi JSON se envía a alguna parte cuando uso esta herramienta?

No. La evaluación de ruta se ejecuta enteramente en el motor JavaScript de tu navegador. Abre la pestaña Red en DevTools y ejecuta una consulta, verás cero solicitudes salientes durante la evaluación. Seguro para respuestas API con secretos, volcados de base de datos con PII, o archivos de configuración que contienen credenciales.