¿Qué es un documento JSON?
Un documento JSON es una pieza de datos estructurados formateada en JavaScript Object Notation (JSON) — un formato ligero basado en texto que los humanos pueden leer y las máquinas pueden parsear. JSON se ha convertido en la lingua franca del intercambio de datos en la web moderna: las APIs devuelven JSON, los archivos de configuración usan JSON, las bases de datos de documentos almacenan JSON, las herramientas de build aceptan JSON, los manifiestos de despliegue usan JSON. Si estás tocando software en 2026, estás tocando documentos JSON constantemente.
A pesar del JavaScript en su nombre, JSON es independiente del lenguaje. Python, Go, Rust, Java, C#, PHP, Ruby — cada lenguaje moderno tiene parsing JSON integrado o casi-estándar. El formato está descrito por RFC 8259 (y ECMA-404), haciéndolo uno de los formatos de datos más estables en uso actual.
Los seis tipos de valor JSON
Un documento JSON está construido a partir de exactamente estos seis tipos — ni más, ni menos:
- Object:
{ "key": value, ... }— conjunto desordenado de pares clave-valor. Las claves siempre son strings. - Array:
[ value, value, ... ]— lista ordenada de valores. - String:
"hello"— texto UTF-8 entre comillas dobles. Las barras hacia adelante pueden ser escapadas opcionalmente; las barras hacia atrás y comillas deben ser escapadas. - Number:
42,3.14,1e10,-7— números decimales. JSON NO distingue entre int y float a nivel de formato. - Boolean:
trueofalse— minúsculas, sin comillas. - Null:
null— explícitamente la ausencia de un valor.
Eso es todo. Sin fechas, sin UUIDs, sin blobs binarios, sin comentarios. Cualquier cosa más allá de estos tipos es una convención superpuesta (fechas ISO 8601 como strings, binario codificado en base64 como strings, etc.).
Un documento JSON canónico
{
"id": "order_42",
"customer": {
"name": "Alice",
"email": "alice@example.com",
"verified": true
},
"items": [
{ "sku": "WIDGET-1", "qty": 2, "price": 9.99 },
{ "sku": "GIZMO-7", "qty": 1, "price": 19.95 }
],
"total": 39.93,
"shipped_at": null,
"tags": ["priority", "gift"]
}Cada valor es uno de los seis tipos. La estructura puede anidarse arbitrariamente profundo, y la misma forma parseará idénticamente en cualquier lenguaje con una librería JSON.
JSON en producción: dónde lo encontrarás
- APIs REST — los cuerpos de petición y respuesta suelen ser JSON. Content type
application/json. - Archivos de configuración —
package.json(Node),tsconfig.json(TypeScript),composer.json(PHP),cargo.toml(Rust usa TOML, pero la mayoría de los ecosistemas adyacentes a JS son JSON). - Bases de datos NoSQL — MongoDB almacena BSON (JSON binario). Couchbase, DynamoDB, Firestore todos exponen APIs con forma de documento.
- Logging — el logging estructurado emite un objeto JSON por línea de log (NDJSON, JSON delimitado por nuevas líneas).
- JSON Schema — describiendo formas JSON para validación. Ampliamente usado en OpenAPI, AJV (validador JS), y muchos pipelines de tooling.
- JSON-LD — JSON para Linked Data. Usado para datos estructurados SEO (FAQPage, BreadcrumbList, Article), el formato que Google usa para rich snippets.
- Manifiestos cloud — AWS CloudFormation, recursos Kubernetes (cuando se autorizan vía JSON), archivos de estado Terraform.
Trampas JSON que todos golpean eventualmente
- No se permiten comas finales.
{"a":1,}es JSON inválido. Los objetos JavaScript permiten comas finales; JSON no. Fuente común de la frustración "mi JSON no se parsea". - Sin comentarios. JSON puro no tiene
//o/* */. Workarounds: JSON5, JSONC, o simplemente embebe comentarios como claves"_comment"(y recuerda eliminarlas antes de los parsers estrictos). - Los números pueden perder precisión. El
JSON.parsede JavaScript almacena todos los números como dobles IEEE 754. Los enteros mayores que 2^53-1 (9,007,199,254,740,991) pierden precisión. Para IDs de 64 bits de bases de datos, serializa como strings. - Las fechas no son un tipo. Siempre serializa como strings ISO 8601 (
"2026-05-07T08:22:00Z") o timestamps Unix (números). Ambos extremos acuerdan cuál. - Las claves duplicadas son técnicamente válidas pero comportamiento indefinido. La mayoría de los parsers toman el último valor. No escribas JSON con claves duplicadas.
- Solo UTF-8. JSON es UTF-8 por defecto. Otras codificaciones (UTF-16, Latin-1) causarán problemas — convierte a UTF-8 en el límite.
- El espacio en blanco no importa para parsing pero importa para diffing. Los diffs de JSON pretty-printed son enormemente más legibles que minificados. Usa un formateador (
jq .,JSON.stringify(x, null, 2)) antes de los commits. - El orden de los campos no es significativo. Dos documentos JSON con las mismas claves en diferente orden son semánticamente idénticos. Herramientas como
jq -Sordenan claves para comparación canónica.
JSON vs. otros formatos de datos
| Formato | Mejor para | Trade-offs |
|---|---|---|
| JSON | APIs, configs, bases de datos de documentos | Verboso, sin comentarios, sin fechas |
| YAML | Configs editados por humanos (CI, K8s) | Sensible al espacio en blanco, casos límite |
| TOML | Configs de app (Rust, Python) | Menos soporte de ecosistema |
| XML | Marcado de documentos, enterprise legacy | Verboso, parsing complejo |
| Protocol Buffers | RPC de alto rendimiento (gRPC) | Binario, requiere esquema |
| MessagePack | Binario equivalente a JSON compacto | Más pequeño, menos depurable |
| BSON | Almacenamiento interno de MongoDB | Añade tipos binario, fecha a JSON |
FAQ: Documentos JSON
¿Cuál es la diferencia entre JSON y objetos JavaScript?
JSON es un subconjunto estricto de la sintaxis literal de objeto JavaScript. JSON puro requiere claves con comillas dobles; JavaScript permite claves sin comillas o con comillas simples. JSON no permite funciones, ni undefined, ni comentarios. JSON.parse valida la forma estricta.
¿Cómo valido JSON?
Online: jsonlint.com. CLI: jq . file.json (parsea + pretty-prints, errores en inválido). Para validación de esquema: AJV (JS), python-jsonschema, JSON Schema Validator.
¿Qué tan grande puede ser un documento JSON?
El formato no impone límite. Los límites prácticos vienen de los parsers (algunos asignan el documento completo en RAM) y APIs (Cloudflare 100MB, AWS API Gateway 10MB, la mayoría de los CDNs ~10MB). Para datos más grandes, usa streaming NDJSON o muévete a Protocol Buffers/Parquet.
¿JSON vs. JSON Lines (NDJSON)?
NDJSON es un documento JSON válido por línea. Usado para streaming y logs append-only — puedes parsear línea por línea sin cargar todo. Los arrays JSON estándar requieren cargar el array completo primero.
¿Qué es JSON Schema?
Un formato basado en JSON para describir cómo se ve un documento JSON válido (campos requeridos, tipos, restricciones). Usado para validación de API, autocompletado IDE (busca tu package.json en VS Code), y validación de config.
¿Debería usar JSON o YAML para configs?
Para configs generados por máquina (salidas de build, locks): JSON. Para configs escritos a mano donde la legibilidad y los comentarios importan (workflows CI, manifiestos K8s): YAML. La línea es difusa y dependiente del ecosistema.
¿Por qué JSON no tiene un tipo fecha?
Porque la spec original era mínima y las fechas JavaScript tienen complicaciones de zona horaria. La convención es serializar fechas como strings ISO 8601; los parsers modernos pueden revivirlas como objetos Date vía lógica personalizada.
Cómo se relaciona LoadFocus con JSON en producción
Los documentos JSON se mueven a través de cada capa de las apps web modernas — payloads de petición, cuerpos de respuesta, entradas de log. Las pruebas de carga de API LoadFocus validan que los endpoints JSON manejan payloads concurrentes realistas sin cuellos de botella de serialización. La monitorización de API valida formas de respuesta vía aserciones JSON Schema, atrapando drift cuando una API silenciosamente descarta un campo.
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus — la misma plataforma que potencia todo lo que acabas de leer.