Convertir JSON a Markdown en línea gratis

Convierta archivos JSON a Markdown en línea de forma gratuita. Cargue su archivo y obtenga una salida limpia y lista para LLM al instante. Sin registro, 50 MB por archivo, nada almacenado.

Convertir JSON a Markdown: de un volcado anidado a algo que de verdad se pueda leer

JSON es un formato de máquina que las personas toleran. Aguanta bien hasta tres niveles de profundidad. A ocho niveles, con un array de 400 objetos plantado en medio, lo que tienes es un muro de llaves y tú intentando adivinar qué corchete de cierre le corresponde a qué. Cualquiera que haya abierto una respuesta de API en crudo en una pestaña del navegador conoce la sensación.

Convertir JSON a Markdown agarra ese árbol y lo reescribe como un documento. Las claves de los objetos pasan a ser encabezados. Los objetos anidados, secciones anidadas. Los arrays de registros parecidos, tablas que recorres con la vista y no con la tecla Ctrl+F. Arrastra un archivo .json a la herramienta de arriba y lo tienes en un par de segundos: gratis, sin registro, límite de 50 MB, no guardamos nada de tu lado.

Qué le pasa a la estructura

La conversión es un recorrido del árbol hacia abajo, y cada construcción de JSON tiene su equivalente en Markdown:

  • Los objetos se vuelven secciones. Una clave de primer nivel como customer se convierte en un encabezado y todo lo que cuelga de ella queda por debajo. La profundidad se traduce en nivel de encabezado, así que la jerarquía que antes tenías que deducir de la indentación ahora se ve de un vistazo.
  • Los pares clave/valor escalares se vuelven líneas etiquetadas. "status": "active" se lee como status: active. Comillas, dos puntos y comas finales desaparecen, y con ellos alrededor de un tercio de los caracteres de un archivo típico.
  • Los arrays de escalares se vuelven listas con viñetas. Una lista de etiquetas o de identificadores deja de parecer una estructura de datos y empieza a parecer una lista.
  • Los arrays de objetos uniformes se vuelven tablas. Este es el caso grande, y tiene su propia sección aquí abajo.
  • Valores vacíos y nulos. Un campo puesto a null, "" o [] no lleva casi información pero cuesta tokens en cada registro donde aparece. Aplanar colapsa ese ruido en lugar de repetirlo 500 veces.

Lo que el JSON crudo hace mal para quien lee es exactamente lo que hace bien para un parser: cada registro repite todas las claves. El JSON muy anidado esconde su forma detrás de la puntuación. Markdown la pone en la superficie.

Arrays de objetos uniformes: de JSON a tabla Markdown

Si tu JSON es una lista de registros que comparten las mismas claves —pedidos, usuarios, productos, entradas de log, resultados de búsqueda—, obtienes el mejor resultado posible: una tabla Markdown, las claves como cabeceras de columna y una fila por registro. Doscientos objetos que ocupaban 3.000 líneas de JSON crudo se reducen a 200 filas de tabla.

El ahorro no es cosmético. En el JSON crudo, cada uno de esos 200 registros repite el nombre de campo "created_at", el nombre de campo "customer_id", y así con el resto. En una tabla, cada nombre aparece exactamente una vez, en la fila de cabecera. Para un LLM peleando con un límite de contexto, esa es la diferencia entre que el conjunto de datos entre o no entre. El contador de tokens debajo de la salida lo hace tangible: convierte el mismo archivo de las dos formas y mira cómo baja el número.

Dónde se degrada: los registros irregulares. Si la mitad de tus objetos tienen un bloque address y los demás no, o si algún campo es a su vez un objeto anidado, una tabla plana no puede representarlo con limpieza. Te saldrá una tabla más ancha con huecos, o el contenido anidado empujado a su propia sección. Si tus datos son realmente tabulares, exportarlos primero a CSV y usar el conversor de CSV a Markdown suele dar tablas más prolijas, porque un CSV no puede ser irregular de entrada.

Cuándo no deberías convertir nada

Conviene decirlo sin rodeos, porque muchas páginas que venden conversores no lo van a hacer: un LLM lee JSON crudo perfectamente. Es un formato del que los modelos han visto cantidades enormes durante el entrenamiento. Nadie te obliga a convertir nada.

Quédate con el JSON crudo cuando las claves exactas importan. Si le estás pidiendo a un modelo que escriba código contra una respuesta de API —una interfaz de TypeScript, un parser, una función de mapeo—, necesita los nombres de clave literales, el anidamiento literal y los tipos literales. Markdown difumina parte de eso a propósito. Pega la carga útil cruda, o una muestra recortada, y deja que el modelo vea lo que realmente va a parsear.

Convierte cuando hay una persona en el circuito, o cuando andas justo de tokens. Quieres entender qué devuelve una API que no conoces. Estás revisando un archivo de configuración que escribió otra persona. Vas a meter una exportación grande en un modelo y el archivo crudo es un 40 % puntuación. Ahí es donde un conversor de JSON a Markdown se gana el sitio. Todo lo demás es cuestión de gustos.

Archivos minificados, indentados y JSON Lines

Aparecen tres variantes todo el rato y se comportan de forma distinta:

  • JSON minificado: una única línea gigantesca, sin espacios. Es el formato que devuelven de verdad casi todas las API. Ilegible para una persona e incómodo también para los modelos, porque no hay saltos de línea donde anclarse. Aquí es donde más ayuda convertir: pasas de una sola línea de 200 KB a un documento estructurado.
  • JSON indentado: ya viene formateado. Se lee mejor, pero esa indentación son ahora miles de espacios iniciales por los que estás pagando tokens. Markdown te da la jerarquía sin la factura de los espacios.
  • NDJSON / JSON Lines: un objeto JSON completo por línea, sin array que los envuelva. Es el estándar para logs y exportaciones en streaming. Por naturaleza es uniforme, lo que lo deja casi perfecto para salida en tabla. Si tu archivo es .jsonl o .ndjson, renómbralo a .json o envuelve las líneas en un array antes de subirlo.

Un aviso práctico: un archivo mal formado no se convierte. Comas de más al final, comillas simples en vez de dobles, saltos de línea sin escapar dentro de las cadenas o un NaN despistado salido de un script de Python fallan todos en la validación. Pasa el archivo por un linter primero si viene de algún sitio raro.

Dónde se usa esto

  • Entender una API sin documentación. Captura una respuesta real, conviértela y ya tienes un esquema legible de la forma de la respuesta: mejor que la documentación de la mayoría de proveedores, y además se lo puedes pasar a un modelo como referencia.
  • Revisar volcados de analítica o exportaciones. Unos miles de eventos de una herramienta de analítica de producto se convierten en una tabla a la que sí puedes hacerle preguntas.
  • Auditar configuración. Manifiestos de Kubernetes, configuraciones de ESLint, ajustes de despliegue: pasados a Markdown, la herencia y las sobrescrituras saltan a la vista de una forma que entre llaves anidadas no ocurre.
  • Escribir documentación. La salida en Markdown entra directa en un README, en una página de wiki o en un sitio de documentación sin reformatear nada.
  • Comparar dos cargas útiles. Convierte el antes y el después y compara el Markdown. Los cambios estructurales destacan muchísimo más que en un diff de JSON lleno de corchetes que se han movido de sitio.

Si el JSON vive dentro de un proyecto, convierte el proyecto

La mayoría de los archivos JSON no van solos. Son un package.json, un archivo de fixtures, un conjunto de datos de prueba, una especificación OpenAPI, y viven dentro de un repositorio junto al código que los lee. Convertir ese archivo aislado le da al modelo los datos pero ninguno de los alrededores.

Cuando la situación es esa, usa mejor el conversor de repositorios de GitHub a texto, o el conversor de carpetas locales si el proyecto está en tu máquina y no lo has subido a ninguna parte. Marca los archivos JSON más los archivos de código que los consumen y obtienes un único bloque de texto con los dos lados de la relación. También hay una versión para GitLab. Para casi todo lo relacionado con desarrollo esta es la mejor jugada; el conversor de un solo archivo es para el JSON que llegó por su cuenta.

Preguntas frecuentes

¿Cómo convierto JSON a Markdown?

Sube el .json aquí arriba y vuelve como Markdown: objetos anidados como niveles de encabezado, arrays de registros uniformes como tablas de barras verticales y las claves como campos etiquetados. Gratis, 50 MB por archivo, sin cuenta. Descárgalo como .md o cópialo a un documento, a una incidencia o a un prompt.

¿Un array de objetos se convierte en una tabla?

Cuando los objetos comparten forma, sí: es el caso que Markdown maneja mejor. Una lista de registros con las mismas claves se convierte en una tabla de barras verticales con una columna por clave, mucho más fácil de recorrer con la vista que el array crudo. Los arrays heterogéneos, donde cada elemento tiene campos distintos, caen de vuelta en secciones, porque no hay un conjunto de columnas coherente que construir.

¿Cómo se las arregla con el anidamiento profundo?

El anidamiento se traduce en profundidad de encabezado, y Markdown se queda sin niveles en ######. Un archivo de configuración anidado ocho niveles toca fondo y las capas más profundas se aplanan contra el nivel de encima. Para estructuras así de hondas, texto plano no es peor: no iba a sobrevivir nada legible por ninguno de los dos caminos.

¿Sirve para documentar la respuesta de una API?

Es una manera rápida de meter una carga útil real en una página de documentación o en un pull request sin formatearla a mano. Pega una respuesta de ejemplo, convierte y tienes una tabla de campos que se renderiza en cualquier sitio donde se renderice Markdown. Lo que no puede deducir es qué campos son opcionales ni qué significan los tipos cuando un valor resulta ser null en tu muestra.

Para un LLM, ¿mejor JSON a Markdown o JSON a texto?

Markdown si la forma lleva significado, es decir, si quieres que el modelo entienda que estos campos pertenecen a aquel objeto. Texto si estás troceando para embeddings, donde los caracteres de sintaxis son ruido que diluye el vector. Para una sola carga útil que quieres que te expliquen, Markdown se lee mejor y cuesta apenas un poco más.

Markdown o texto plano, y qué más hay por aquí

Si no quieres estructura ninguna —porque estás generando embeddings, indexando para búsqueda o exprimiendo un archivo hasta el mínimo recuento de tokens posible—, tira por JSON a texto plano. Ese camino elimina la sintaxis del todo en vez de traducirla. El selector de formato al principio de esta página alterna entre los dos y arrastra consigo el archivo que ya elegiste, así que puedes probar los dos sin subirlo dos veces.

Para otros formatos estructurados, XML a Markdown se ocupa de feeds, cargas SOAP y esquemas corporativos, y HTML a Markdown se ocupa de las páginas web guardadas. File2Txt es la puerta de entrada general si prefieres no elegir página: acepta también PDF, archivos de Office, imágenes y archivos comprimidos. Hay un texto más largo sobre cómo preparar archivos para modelos de lenguaje si te interesa el argumento completo.

Repo2Txt está creado y mantenido por v12hero, un desarrollador independiente que crea aplicaciones nativas y web centradas en la privacidad.