JSON

JSON, sigla de JavaScript Object Notation y traducido como notación de objetos de JavaScript, es un formato textual ligero utilizado para representar, almacenar e intercambiar datos estructurados. Permite organizar información mediante objetos, arreglos, cadenas de texto, números, valores booleanos y valores nulos, utilizando una sintaxis independiente del lenguaje de programación que puede ser procesada por aplicaciones desarrolladas con tecnologías diferentes.

JSON se utiliza ampliamente para comunicar frontends, backends, API, aplicaciones móviles, bases de datos, servicios en la nube, herramientas de automatización y plataformas de inteligencia artificial. Su sencillez, legibilidad y compatibilidad han permitido que se convierta en uno de los formatos de intercambio de datos más utilizados dentro de la World Wide Web.

En marketing digital, JSON permite transferir catálogos de productos, eventos de analítica, contactos, campañas, conversiones, audiencias, configuraciones, contenidos, respuestas de formularios y datos estructurados para SEO. También funciona como base para formatos especializados como JSON-LD, utilizado para relacionar información con vocabularios semánticos como Schema.org.

Introducción

Las aplicaciones digitales necesitan intercambiar información entre sistemas que pueden estar desarrollados con lenguajes, plataformas y arquitecturas diferentes. Un sitio web puede utilizar JavaScript dentro del navegador, PHP o Python en el servidor, PostgreSQL como base de datos y servicios externos proporcionados mediante API.

Para que estos componentes puedan comunicarse, necesitan una representación compartida de los datos. JSON proporciona una sintaxis textual compacta que puede producirse, transmitirse, almacenarse y analizarse en numerosos lenguajes.

Un documento JSON puede representar información sencilla:

<syntaxhighlight lang="json"> {

 "nombre": "WikiMarketing",
 "idioma": "es",
 "activo": true

} </syntaxhighlight>

También puede representar estructuras más complejas:

<syntaxhighlight lang="json"> {

 "cliente": {
   "id": 105,
   "nombre": "Empresa Ejemplo",
   "correo": "contacto@ejemplo.com"
 },
 "productos": [
   {
     "sku": "BAT-001",
     "nombre": "Batería automotriz",
     "cantidad": 2,
     "precio": 1899.50
   },
   {
     "sku": "CAR-004",
     "nombre": "Cargador",
     "cantidad": 1,
     "precio": 650
   }
 ],
 "total": 4449,
 "pagado": false,
 "cupon": null

} </syntaxhighlight>

La información se organiza mediante pares formados por un nombre y un valor. Los valores pueden contener otros objetos o arreglos, lo que permite construir estructuras jerárquicas.

JSON se originó dentro del ecosistema de JavaScript, aunque se encuentra diseñado como un formato independiente del lenguaje. Python, Java, PHP, C#, Go, Ruby, Rust y numerosos lenguajes incluyen bibliotecas para convertir estructuras internas hacia JSON y reconstruirlas posteriormente.

La conversión de una estructura interna hacia JSON se denomina habitualmente serialización. El proceso inverso, donde un texto JSON se transforma en estructuras utilizadas por un programa, se denomina deserialización o parsing.

JSON describe datos y carece de instrucciones ejecutables. Un documento JSON válido no contiene funciones, clases, ciclos, condiciones ni expresiones del lenguaje JavaScript.

Esta distinción resulta importante porque un objeto escrito dentro de código JavaScript puede parecerse a JSON y contener características que el formato no permite.

El siguiente fragmento es válido como objeto JavaScript:

<syntaxhighlight lang="javascript"> const producto = {

 nombre: "Batería",
 disponible: true,
 calcularPrecio() {
   return 1500;
 }

}; </syntaxhighlight>

La misma estructura no constituye JSON válido porque los nombres de las propiedades carecen de comillas dobles y contiene una función.

JSON se utiliza principalmente como formato de intercambio y persistencia. Su significado depende de la aplicación, el contrato de una API, un esquema, una especificación o un acuerdo entre los sistemas participantes.

El formato permite declarar que un campo contiene el número `100`, pero no establece por sí mismo si representa pesos, dólares, unidades, porcentaje o segundos. Esa semántica debe definirse externamente.

Definición

JSON puede definirse como una sintaxis textual, ligera e independiente del lenguaje para representar valores estructurados y transportarlos entre sistemas informáticos.

RFC 8259 y ECMA-404 constituyen las principales especificaciones normativas del formato. Ambas describen una gramática pequeña basada en dos estructuras principales:

Objeto. Colección de pares nombre-valor delimitada mediante llaves.

Arreglo. Secuencia ordenada de valores delimitada mediante corchetes.

Los valores permitidos son:

objeto;
arreglo;
cadena de caracteres;
número;
`true`;
`false`;
`null`.

Una definición operativa puede apoyarse en los siguientes criterios:

Formato textual: JSON se representa mediante caracteres y puede almacenarse en archivos o transmitirse mediante redes.

Estructura jerárquica: los objetos y arreglos pueden anidarse.

Independencia del lenguaje: puede producirse y consumirse desde numerosos lenguajes.

Conjunto reducido de tipos: utiliza objetos, arreglos, cadenas, números, booleanos y nulos.

Intercambio de datos: se utiliza para comunicar sistemas y procesos.

Serialización: transforma estructuras internas en una representación transportable.

Legibilidad relativa: las personas pueden leer y editar documentos pequeños.

Procesamiento automático: los programas pueden analizar su gramática de manera eficiente.

Ausencia de comportamiento: representa datos y no contiene lógica ejecutable.

Semántica externa: el significado de cada propiedad debe definirse mediante documentación, esquemas o contratos.

Un texto JSON puede contener un objeto o arreglo como valor principal:

<syntaxhighlight lang="json"> [

 "marketing",
 "publicidad",
 "ventas"

] </syntaxhighlight>

También puede consistir en un valor escalar:

<syntaxhighlight lang="json"> "WikiMarketing" </syntaxhighlight>

Las versiones antiguas de determinadas especificaciones exigían que el nivel superior fuera un objeto o arreglo. RFC 8259 permite cualquier valor JSON válido como documento completo.

Terminología

JSON. Sigla de JavaScript Object Notation.

Documento JSON. Texto completo que cumple la sintaxis de JSON.

Texto JSON. Secuencia de caracteres que representa un valor JSON válido.

Valor JSON. Objeto, arreglo, cadena, número, booleano o nulo.

Objeto JSON. Colección de miembros delimitada por llaves.

Miembro. Par formado por un nombre y un valor dentro de un objeto.

Nombre de propiedad. Cadena situada antes de los dos puntos dentro de un miembro.

Clave. Nombre utilizado para localizar un valor dentro de un objeto. El término es común, aunque las especificaciones utilizan expresiones como nombre o member name.

Arreglo JSON. Secuencia ordenada de valores delimitada por corchetes.

Serialización. Conversión de una estructura interna hacia JSON.

Deserialización. Conversión de JSON hacia una estructura interna.

Parser. Programa o biblioteca que analiza y convierte el texto.

Generador JSON. Programa que produce documentos JSON válidos.

Payload. Cuerpo de datos enviado dentro de una solicitud, respuesta, mensaje o evento.

JSON minificado. Documento donde se eliminan espacios y saltos de línea innecesarios.

Pretty-printed JSON. Documento presentado con sangría y saltos para facilitar lectura.

Esquema JSON. Descripción de la estructura y restricciones esperadas en un documento, generalmente mediante JSON Schema.

JSON válido. Texto que cumple la gramática del formato.

JSON bien formado. Expresión equivalente a JSON sintácticamente válido.

JSON semánticamente válido. Documento que además cumple las reglas definidas por la aplicación o esquema.

Media type. Identificador utilizado para describir el tipo de contenido transmitido. El tipo registrado para JSON es `application/json`.

Contexto histórico y evolución

Los antecedentes de JSON se encuentran en los lenguajes de programación, la representación de estructuras de datos y la necesidad de intercambiar información entre aplicaciones.

Representaciones anteriores

Antes de JSON, los sistemas utilizaban numerosos formatos para transmitir información.

Entre ellos se encontraban:

archivos delimitados;
formatos binarios;
mensajes propietarios;
CSV;
SGML;
XML;
pares clave-valor;
serializaciones específicas de cada lenguaje.

XML adquirió gran relevancia durante la década de 1990 y los primeros años del siglo XXI. Permitía construir documentos jerárquicos, incorporar espacios de nombres, validar estructuras y transformar información.

Numerosas aplicaciones web utilizaban XML para comunicarse mediante tecnologías como SOAP, XML-RPC y Ajax.

La flexibilidad de XML también implicaba una sintaxis más extensa, debido al uso de etiquetas de apertura y cierre, atributos, declaraciones y espacios de nombres.

Objetos de JavaScript

JavaScript utilizaba una notación literal para representar objetos y arreglos dentro del código.

Un objeto podía expresarse de esta forma:

<syntaxhighlight lang="javascript"> {

 nombre: "Producto",
 precio: 100

} </syntaxhighlight>

Esta notación resultaba compacta y cercana a las estructuras internas utilizadas por programas.

Douglas Crockford identificó que un subconjunto de esta sintaxis podía utilizarse como formato independiente para intercambiar datos.

Aparición de JSON

JSON fue presentado públicamente mediante el sitio JSON.org en 2001. El formato se promovió como una alternativa textual ligera y compatible con diferentes lenguajes.

Su adopción aumentó con el crecimiento de aplicaciones web dinámicas y solicitudes asíncronas.

Aunque la letra J de JSON procede de JavaScript, el formato se diseñó para ser independiente del lenguaje. Sus estructuras básicas corresponden con conceptos presentes en numerosos lenguajes:

objetos;
diccionarios;
mapas;
hashes;
listas;
arreglos;
cadenas;
números;
booleanos;
valores nulos.

Ajax

La popularización de Ajax durante la década de 2000 aumentó la demanda de formatos ligeros para transferir datos entre navegador y servidor.

La expresión Ajax significaba originalmente Asynchronous JavaScript and XML. En la práctica, JSON reemplazó progresivamente a XML dentro de numerosas aplicaciones debido a su menor verbosidad y facilidad de integración con JavaScript.

Las solicitudes podían obtener información como:

<syntaxhighlight lang="json"> {

 "resultado": "correcto",
 "usuario": {
   "id": 12,
   "nombre": "Ana"
 }

} </syntaxhighlight>

JavaScript podía analizar el texto y convertirlo en valores utilizables por la interfaz.

RFC 4627

En julio de 2006, el IETF publicó RFC 4627, titulado The application/json Media Type for JavaScript Object Notation.

Este documento formalizó la sintaxis y registró el tipo de contenido `application/json`.

RFC 4627 describía JSON como un formato textual para serializar datos estructurados y establecía que el nivel superior debía consistir en un objeto o arreglo.

Integración en ECMAScript

ECMAScript incorporó una definición normativa de JSON y funciones estándar para analizar y producir documentos.

JavaScript proporciona actualmente el objeto global `JSON`, con métodos principales:

`JSON.parse()`;
`JSON.stringify()`.

Estas funciones eliminaron la necesidad de interpretar documentos mediante `eval()`, una práctica insegura utilizada en implementaciones anteriores.

ECMA-404

Ecma International publicó ECMA-404 en 2013 bajo el título The JSON Data Interchange Syntax.

La segunda edición fue publicada en diciembre de 2017.

ECMA-404 define la sintaxis del formato y evita establecer semánticas específicas para las estructuras representadas.

RFC 7158 y RFC 7159

El IETF publicó nuevas especificaciones para corregir inconsistencias, ampliar interoperabilidad y permitir valores escalares en el nivel superior.

RFC 7159 reemplazó RFC 4627 y fue posteriormente sustituido por RFC 8259.

RFC 8259

RFC 8259 fue publicado en diciembre de 2017 y se convirtió en la referencia principal del IETF para JSON.

El documento armoniza la definición con ECMA-404 y proporciona recomendaciones de interoperabilidad relacionadas con:

codificación;
números;
nombres duplicados;
caracteres;
parsers;
generadores.

RFC 8259 fue clasificado posteriormente como Internet Standard STD 90.

I-JSON

RFC 7493 definió I-JSON, abreviatura de Internet JSON, como un perfil restringido orientado a aumentar la interoperabilidad.

I-JSON establece recomendaciones como:

utilizar UTF-8;
evitar nombres duplicados;
utilizar números dentro de rangos interoperables;
representar fechas mediante formatos definidos;
evitar caracteres Unicode problemáticos.

I-JSON no sustituye a JSON. Define un subconjunto más estricto para comunicaciones donde la interoperabilidad resulta crítica.

JSON Schema

La necesidad de describir estructuras, tipos y restricciones produjo el desarrollo de JSON Schema.

JSON Schema permite expresar condiciones como:

propiedades obligatorias;
tipos;
longitudes;
rangos numéricos;
patrones;
enumeraciones;
estructuras anidadas;
referencias;
combinaciones lógicas.

La versión publicada más reciente de JSON Schema continúa siendo Draft 2020-12.

JSON-LD

JSON-LD fue desarrollado para representar Linked Data mediante una sintaxis compatible con JSON.

Permite relacionar propiedades con vocabularios y entidades identificables globalmente.

JSON-LD adquirió gran importancia dentro del SEO porque los buscadores utilizan datos estructurados para comprender productos, organizaciones, eventos, artículos, preguntas, reseñas y otras entidades.

Estandarizaciones complementarias

El ecosistema JSON incluye especificaciones adicionales:

JSON Pointer;
JSON Patch;
JSON Merge Patch;
JSON Text Sequences;
JSONPath;
GeoJSON;
JSON Type Definition;
JSON Canonicalization Scheme;
JSON Web Token;
JSON Web Key.

Estas especificaciones amplían el formato para selección, actualización, validación, geografía, seguridad, transmisión secuencial y canonicalización.

Fundamentos teóricos

JSON se apoya en un modelo de datos jerárquico formado por valores simples y compuestos.

Valores simples

Los valores simples son:

cadena;
número;
booleano;
nulo.

Valores compuestos

Los valores compuestos son:

objeto;
arreglo.

Los objetos permiten asociar nombres con valores. Los arreglos permiten organizar valores según una posición.

Árbol de datos

Un documento JSON puede representarse conceptualmente como un árbol.

Cada objeto y arreglo funciona como nodo contenedor. Las cadenas, números, booleanos y nulos funcionan generalmente como hojas.

Por ejemplo:

<syntaxhighlight lang="json"> {

 "campaña": {
   "nombre": "Promoción de verano",
   "canales": [
     "Facebook",
     "Google Ads",
     "Correo electrónico"
   ],
   "presupuesto": 25000
 }

} </syntaxhighlight>

La raíz es un objeto. La propiedad `campaña` contiene otro objeto. `canales` contiene un arreglo de cadenas.

Orden

Los elementos de un arreglo poseen un orden definido.

Los miembros de un objeto se consideran una colección sin orden semántico. Determinadas implementaciones conservan el orden de inserción, aunque las aplicaciones no deberían depender de él salvo que una especificación adicional lo garantice.

Cuando el orden forma parte del significado, debe utilizarse un arreglo.

Nombres de propiedades

Los nombres de las propiedades deben ser cadenas delimitadas mediante comillas dobles.

Ejemplo válido:

<syntaxhighlight lang="json"> {

 "nombre": "Producto"

} </syntaxhighlight>

Ejemplos inválidos:

<syntaxhighlight lang="text"> {

 nombre: "Producto"

} </syntaxhighlight>

<syntaxhighlight lang="text"> {

 'nombre': 'Producto'

} </syntaxhighlight>

JSON no permite utilizar comillas simples como delimitadores de cadenas.

Nombres duplicados

La gramática permite que un objeto contenga más de un miembro con el mismo nombre:

<syntaxhighlight lang="json"> {

 "precio": 100,
 "precio": 200

} </syntaxhighlight>

El comportamiento de los parsers puede variar:

conservar el último valor;
conservar el primero;
mantener todos;
generar un error.

Para garantizar interoperabilidad, los nombres deberían ser únicos dentro de cada objeto.

Cadenas

Las cadenas se escriben entre comillas dobles:

<syntaxhighlight lang="json"> "Marketing digital" </syntaxhighlight>

Determinados caracteres deben escaparse mediante una barra invertida.

Ejemplos:

`\"` para comillas;
`\\` para barra invertida;
`\/` para barra diagonal opcionalmente escapada;
`\b` para retroceso;
`\f` para salto de página;
`\n` para nueva línea;
`\r` para retorno de carro;
`\t` para tabulación;
`\uXXXX` para una unidad codificada mediante hexadecimal.

Ejemplo:

<syntaxhighlight lang="json"> {

 "mensaje": "Primera línea\nSegunda línea",
 "ruta": "C:\\archivos\\reporte.json",
 "titulo": "\"Promoción especial\""

} </syntaxhighlight>

Unicode

JSON utiliza Unicode para representar texto.

RFC 8259 establece que los sistemas que intercambian JSON fuera de ecosistemas cerrados deben utilizar UTF-8.

UTF-8 permite representar idiomas, alfabetos, símbolos y emojis.

La longitud de una cadena en caracteres visibles puede diferir de su longitud en bytes, unidades UTF-16 o puntos de código.

Números

JSON permite números enteros y decimales, con parte exponencial opcional.

Ejemplos válidos:

<syntaxhighlight lang="json"> [

 0,
 -25,
 1500,
 19.99,
 6.022e23,
 -2.5E-4

] </syntaxhighlight>

JSON no permite:

ceros iniciales innecesarios;
signo positivo inicial;
hexadecimal;
`NaN`;
`Infinity`;
`-Infinity`.

Ejemplos inválidos:

<syntaxhighlight lang="text"> [

 01,
 +20,
 0xFF,
 NaN,
 Infinity

] </syntaxhighlight>

La especificación no establece un límite universal para precisión o tamaño. Las implementaciones utilizan diferentes representaciones numéricas.

JavaScript utiliza habitualmente números de punto flotante IEEE 754 de doble precisión. Los enteros mayores que `9007199254740991` pueden perder exactitud.

Para identificadores, números financieros de precisión estricta o enteros extremadamente grandes, puede resultar conveniente transmitir el valor como cadena:

<syntaxhighlight lang="json"> {

 "numero_factura": "98765432101234567890",
 "importe": "15499.99",
 "moneda": "MXN"

} </syntaxhighlight>

La aplicación debe documentar cómo interpretar estas cadenas.

Booleanos

Los valores booleanos se representan exclusivamente mediante:

<syntaxhighlight lang="json"> false </syntaxhighlight>

Deben escribirse en minúsculas.

Null

`null` representa la ausencia intencional de un valor o un valor vacío, según el contrato utilizado.

<syntaxhighlight lang="json"> {

 "fecha_cancelacion": null

} </syntaxhighlight>

`null` puede diferenciarse de una propiedad ausente.

Los siguientes documentos pueden tener significados diferentes:

<syntaxhighlight lang="json"> {

 "telefono": null

} </syntaxhighlight>

En el primer caso, la propiedad existe y posee un valor nulo. En el segundo, la propiedad no fue incluida.

Objetos

Un objeto se delimita mediante llaves.

Sus miembros se separan mediante comas y cada nombre se separa de su valor mediante dos puntos.

<syntaxhighlight lang="json"> {

 "id": 25,
 "nombre": "Cliente",
 "activo": true

} </syntaxhighlight>

Un objeto vacío se representa como:

Arreglos

Un arreglo se delimita mediante corchetes.

<syntaxhighlight lang="json"> [

 "SEO",
 "SEM",
 "Marketing de contenidos"

] </syntaxhighlight>

Los arreglos pueden contener valores de tipos diferentes:

<syntaxhighlight lang="json"> [

 10,
 "diez",
 true,
 null,
 {
   "valor": 10
 }

] </syntaxhighlight>

Aunque el formato permite heterogeneidad, los contratos y esquemas pueden exigir que todos los elementos compartan una estructura.

Un arreglo vacío se representa como:

Espacios en blanco

JSON permite espacios, tabulaciones y saltos de línea entre elementos estructurales.

Los siguientes documentos representan el mismo valor:

<syntaxhighlight lang="json"> {"nombre":"Producto","precio":100} </syntaxhighlight>

<syntaxhighlight lang="json"> {

 "nombre": "Producto",
 "precio": 100

} </syntaxhighlight>

Los espacios dentro de una cadena forman parte del valor y no pueden eliminarse.

Comentarios

JSON no permite comentarios.

El siguiente ejemplo es inválido:

<syntaxhighlight lang="text"> {

 // Nombre comercial
 "nombre": "Producto"

} </syntaxhighlight>

Las aplicaciones que necesitan comentarios pueden utilizar:

una propiedad específica como `$comment`;
documentación separada;
JSON Schema;
formatos extendidos como JSON5;
YAML;
archivos de configuración con otra sintaxis.

Comas finales

JSON no permite una coma después del último miembro o elemento.

Ejemplo inválido:

<syntaxhighlight lang="text"> {

 "nombre": "Producto",
 "precio": 100,

} </syntaxhighlight>

Fechas

JSON carece de un tipo de fecha.

Las fechas se representan generalmente mediante cadenas:

<syntaxhighlight lang="json"> {

 "fecha_publicacion": "2026-07-14T15:30:00-06:00"

} </syntaxhighlight>

La aplicación debe definir el formato, zona horaria y precisión.

RFC 3339 e ISO 8601 se utilizan frecuentemente para fechas y horas interoperables.

Datos binarios

JSON carece de un tipo binario.

Las opciones incluyen:

codificación Base64;
URL hacia el archivo;
transmisión multipart;
almacenamiento separado;
formato binario especializado.

Incluir archivos grandes mediante Base64 aumenta el tamaño y consumo de memoria.

Canonicalización

Dos documentos JSON pueden representar el mismo valor aunque utilicen espacios u orden de propiedades diferentes.

Ejemplo:

<syntaxhighlight lang="json"> {

 "b": 2,
 "a": 1

} </syntaxhighlight>

Esta variabilidad dificulta calcular firmas y hashes sobre el texto original.

RFC 8785 define JSON Canonicalization Scheme, que establece reglas para producir una representación determinista y utilizable en procesos criptográficos.

Metodología

La utilización de JSON dentro de una aplicación puede organizarse mediante una metodología orientada a contratos e interoperabilidad.

1. Definir el propósito. Se determina qué información debe intercambiarse y entre qué sistemas.

2. Identificar entidades. Se enumeran clientes, productos, campañas, pedidos, eventos u otros conceptos.

3. Definir propiedades. Se especifican nombres, tipos, significado y obligatoriedad.

4. Seleccionar estructuras. Se decide qué datos requieren objetos, arreglos o valores escalares.

5. Definir identificadores. Se establecen formatos estables para relacionar registros.

6. Especificar fechas y horas. Se documentan formato, zona horaria y precisión.

7. Especificar números. Se define tratamiento de moneda, porcentajes, enteros grandes y decimales.

8. Definir valores ausentes. Se establece la diferencia entre propiedad omitida, cadena vacía y `null`.

9. Diseñar nombres consistentes. Se elige una convención como camelCase, snake_case o nombres en español.

10. Elaborar ejemplos. Se crean documentos representativos y casos extremos.

11. Crear un esquema. JSON Schema puede utilizarse para expresar restricciones.

12. Validar entradas. Todo documento recibido debe verificarse antes de procesarse.

13. Serializar con bibliotecas confiables. Los programas deben evitar construir JSON mediante concatenación manual.

14. Definir codificación. UTF-8 debe utilizarse en intercambios abiertos.

15. Establecer límites. Se controlan tamaño, profundidad, número de propiedades y longitud de cadenas.

16. Diseñar errores. Las API deben devolver mensajes y códigos comprensibles.

17. Versionar contratos. Los cambios incompatibles necesitan una estrategia de evolución.

18. Probar interoperabilidad. Los documentos deben procesarse en los lenguajes y plataformas participantes.

19. Proteger datos sensibles. Las propiedades confidenciales deben minimizarse, cifrarse o eliminarse.

20. Documentar el contrato. Los consumidores necesitan conocer significado, restricciones y ejemplos.

21. Monitorear fallos. Los errores de parsing y validación deben registrarse.

22. Retirar propiedades obsoletas. Los campos sin uso deben eliminarse mediante un proceso controlado.

Elementos principales

Pares nombre-valor

Los miembros de un objeto relacionan un nombre textual con un valor.

<syntaxhighlight lang="json"> {

 "estado": "publicado"

} </syntaxhighlight>

Estructuras anidadas

JSON permite representar relaciones mediante anidamiento:

<syntaxhighlight lang="json"> {

 "empresa": {
   "nombre": "Empresa Ejemplo",
   "direccion": {
     "ciudad": "Ciudad de México",
     "pais": "México"
   }
 }

} </syntaxhighlight>

El anidamiento excesivo puede dificultar consultas, validación y mantenimiento.

Identificadores

Los identificadores permiten relacionar objetos sin repetir toda su información.

<syntaxhighlight lang="json"> {

 "pedido_id": "PED-2026-0001",
 "cliente_id": "CLI-105"

} </syntaxhighlight>

Metadatos

Los metadatos describen el documento o recurso:

<syntaxhighlight lang="json"> {

 "data": [
   {
     "id": 1,
     "nombre": "Producto"
   }
 ],
 "meta": {
   "pagina": 1,
   "total": 250,
   "generado_en": "2026-07-14T15:30:00-06:00"
 }

} </syntaxhighlight>

Paginación

Las API pueden representar páginas, límites y enlaces:

<syntaxhighlight lang="json"> {

 "data": [],
 "pagination": {
   "page": 2,
   "per_page": 50,
   "total_pages": 8,
   "total_items": 375
 },
 "links": {
   "previous": "/productos?page=1",
   "next": "/productos?page=3"
 }

} </syntaxhighlight>

Errores

Una respuesta de error puede incluir código, mensaje y detalles:

<syntaxhighlight lang="json"> {

 "error": {
   "code": "VALIDATION_ERROR",
   "message": "Los datos enviados no son válidos",
   "details": [
     {
       "field": "correo",
       "message": "Debe contener una dirección válida"
     }
   ]
 }

} </syntaxhighlight>

La estructura debe mantenerse consistente entre endpoints.

Envelopes

Un envelope o envoltorio añade propiedades alrededor del dato principal:

<syntaxhighlight lang="json"> {

 "success": true,
 "data": {
   "id": 25
 }

} </syntaxhighlight>

Puede facilitar metadatos y errores, aunque añade niveles adicionales.

HATEOAS y enlaces

Una representación puede incluir enlaces hacia acciones y recursos relacionados:

<syntaxhighlight lang="json"> {

 "id": 25,
 "estado": "pendiente",
 "links": {
   "self": "/pedidos/25",
   "pagar": "/pedidos/25/pago",
   "cancelar": "/pedidos/25/cancelacion"
 }

} </syntaxhighlight>

Versiones

La versión puede declararse en la URL, encabezados o cuerpo:

<syntaxhighlight lang="json"> {

 "schema_version": "2.0",
 "data": {}

} </syntaxhighlight>

La estrategia debe evitar cambios inesperados para consumidores existentes.

Serialización y deserialización

La serialización convierte valores internos hacia texto JSON.

En JavaScript:

<syntaxhighlight lang="javascript"> const cliente = {

 id: 25,
 nombre: "Ana",
 activo: true

};

const texto = JSON.stringify(cliente); </syntaxhighlight>

El resultado es:

<syntaxhighlight lang="json"> {"id":25,"nombre":"Ana","activo":true} </syntaxhighlight>

La deserialización convierte el texto hacia un valor JavaScript:

<syntaxhighlight lang="javascript"> const texto = '{"id":25,"nombre":"Ana","activo":true}'; const cliente = JSON.parse(texto); </syntaxhighlight>

Los lenguajes utilizan nombres diferentes:

Python: `json.dumps()` y `json.loads()`;
PHP: `json_encode()` y `json_decode()`;
Java: bibliotecas como Jackson o Gson;
C#: `System.Text.Json`;
Go: `json.Marshal()` y `json.Unmarshal()`;
Ruby: `JSON.generate()` y `JSON.parse()`.

La serialización puede perder información cuando los tipos internos carecen de una equivalencia directa.

Ejemplos:

fechas;
mapas con claves no textuales;
conjuntos;
funciones;
objetos con referencias circulares;
números especiales;
tipos binarios;
clases.

Los sistemas deben definir reglas explícitas para estos casos.

Validación mediante JSON Schema

JSON por sí mismo valida únicamente sintaxis.

El siguiente documento es JSON válido:

<syntaxhighlight lang="json"> {

 "correo": 25,
 "edad": "muchos años"

} </syntaxhighlight>

Una aplicación puede esperar que `correo` sea una cadena y `edad` sea un número. Esta regla pertenece al contrato, no a la gramática de JSON.

JSON Schema permite expresar estas condiciones:

<syntaxhighlight lang="json"> {

 "$schema": "https://json-schema.org/draft/2020-12/schema",
 "type": "object",
 "required": [
   "correo",
   "edad"
 ],
 "properties": {
   "correo": {
     "type": "string",
     "format": "email"
   },
   "edad": {
     "type": "integer",
     "minimum": 18
   }
 },
 "additionalProperties": false

} </syntaxhighlight>

Un documento válido según el esquema sería:

<syntaxhighlight lang="json"> {

 "correo": "persona@ejemplo.com",
 "edad": 35

} </syntaxhighlight>

JSON Schema puede utilizarse para:

validar API;
generar formularios;
documentar contratos;
producir código;
comprobar configuraciones;
crear datos de prueba;
verificar compatibilidad.

La compatibilidad depende de que el validador admita el dialecto y las palabras clave utilizadas.

Tipos y variantes

JSON estándar

Cumple la sintaxis definida por RFC 8259 y ECMA-404.

JSON minificado

Elimina espacios innecesarios para reducir tamaño.

<syntaxhighlight lang="json"> {"id":1,"activo":true} </syntaxhighlight>

JSON formateado

Utiliza sangría y saltos para facilitar lectura.

<syntaxhighlight lang="json"> {

 "id": 1,
 "activo": true

} </syntaxhighlight>

JSON Schema

Lenguaje declarativo utilizado para describir y validar documentos JSON.

JSON-LD

Formato basado en JSON destinado a representar datos enlazados y semántica web.

Ejemplo:

<syntaxhighlight lang="json"> {

 "@context": "https://schema.org",
 "@type": "Organization",
 "name": "Empresa Ejemplo",
 "url": "https://www.ejemplo.com"

} </syntaxhighlight>

GeoJSON

Formato basado en JSON para representar geometrías, características y colecciones geográficas.

<syntaxhighlight lang="json"> {

 "type": "Point",
 "coordinates": [
   -99.1332,
   19.4326
 ]

} </syntaxhighlight>

JSON Pointer

RFC 6901 define una sintaxis para identificar un valor concreto dentro de un documento.

Dado:

<syntaxhighlight lang="json"> {

 "productos": [
   {
     "nombre": "Batería"
   }
 ]

} </syntaxhighlight>

El puntero:

<syntaxhighlight lang="text"> /productos/0/nombre </syntaxhighlight>

identifica el valor `"Batería"`.

JSON Patch

RFC 6902 define una secuencia de operaciones para modificar un documento.

<syntaxhighlight lang="json"> [

 {
   "op": "replace",
   "path": "/precio",
   "value": 1999
 }

] </syntaxhighlight>

Las operaciones incluyen:

add;
remove;
replace;
move;
copy;
test.

JSON Merge Patch

RFC 7396 representa cambios mediante un documento que se parece al objeto final.

<syntaxhighlight lang="json"> {

 "precio": 1999,
 "descripcion": null

} </syntaxhighlight>

En este contexto, `null` puede utilizarse para eliminar una propiedad, según las reglas de JSON Merge Patch.

JSON Text Sequences

RFC 7464 define una forma de transmitir múltiples textos JSON dentro de una secuencia.

Cada documento se precede mediante un carácter separador de registro.

Resulta útil para:

logs;
flujos;
grandes conjuntos;
procesamiento incremental.

JSON Lines

JSON Lines, también denominado NDJSON en determinados ecosistemas, almacena un valor JSON por línea.

Ejemplo:

<syntaxhighlight lang="json"> {"id":1,"nombre":"Ana"} {"id":2,"nombre":"Luis"} {"id":3,"nombre":"Marta"} </syntaxhighlight>

Resulta práctico para procesamiento secuencial, registros y conjuntos de datos.

No debe confundirse con un arreglo JSON completo.

JSONPath

RFC 9535 define expresiones para seleccionar valores dentro de documentos JSON.

Una expresión como:

<syntaxhighlight lang="text"> $.productos[*].precio </syntaxhighlight>

puede seleccionar los precios de todos los productos.

JSONPath ofrece consultas más flexibles que JSON Pointer.

I-JSON

Perfil restringido diseñado para aumentar interoperabilidad.

JSON Canonicalization Scheme

Define una serialización determinista para firmas, hashes y comparación criptográfica.

JSON Type Definition

RFC 8927 define un lenguaje de esquemas limitado y orientado a validación y generación de código.

JSON5

Extensión no estándar de JSON que permite determinadas características adicionales:

comentarios;
comillas simples;
claves sin comillas en ciertos casos;
comas finales;
números adicionales.

Un documento JSON5 no necesariamente es JSON válido.

BSON

Binary JSON es un formato binario utilizado principalmente por MongoDB.

Añade tipos como:

fecha;
datos binarios;
identificadores;
enteros de diferentes tamaños.

BSON no es una representación textual de JSON y puede tener un tamaño mayor en determinados casos.

MessagePack

Formato binario inspirado en estructuras semejantes a JSON.

Busca reducir tamaño y costo de parsing.

JSON Web Token

JSON Web Token representa claims mediante estructuras JSON codificadas y protegidas criptográficamente.

Un JWT no es simplemente un archivo JSON. Utiliza una serialización específica y codificación Base64URL.

JSON Web Key

Formato JSON destinado a representar claves criptográficas.

Aplicaciones generales

JSON se utiliza en numerosos campos.

API web

Las API REST y GraphQL utilizan frecuentemente JSON para solicitudes y respuestas.

Ejemplo de solicitud:

<syntaxhighlight lang="json"> {

 "nombre": "Nuevo cliente",
 "correo": "cliente@ejemplo.com"

} </syntaxhighlight>

Ejemplo de respuesta:

<syntaxhighlight lang="json"> {

 "id": 501,
 "nombre": "Nuevo cliente",
 "correo": "cliente@ejemplo.com",
 "created_at": "2026-07-14T15:30:00-06:00"

} </syntaxhighlight>

Aplicaciones móviles

Las aplicaciones móviles consumen datos JSON desde servicios remotos para mostrar usuarios, productos, mensajes y configuraciones.

Archivos de configuración

Numerosas herramientas utilizan archivos JSON para definir:

dependencias;
scripts;
preferencias;
permisos;
entornos;
compilaciones;
despliegues.

Ejemplos conocidos incluyen `package.json`, `tsconfig.json` y determinados archivos de configuración de proyectos.

Bases de datos

Las bases documentales almacenan estructuras semejantes a JSON.

Las bases relacionales modernas también pueden incluir columnas JSON y funciones para consultar propiedades internas.

Mensajería

Los sistemas de eventos pueden transportar mensajes JSON entre servicios.

Internet de las cosas

Los dispositivos pueden intercambiar telemetría, estados y comandos mediante JSON.

En sistemas con recursos muy limitados pueden preferirse formatos binarios más compactos.

Inteligencia artificial

Los modelos y agentes utilizan JSON para:

llamadas a herramientas;
respuestas estructuradas;
intercambio de configuraciones;
datasets;
evaluaciones;
resultados.

Automatización

Herramientas como n8n, Zapier y Make intercambian datos mediante estructuras JSON durante los flujos.

Exportaciones e importaciones

Las aplicaciones pueden permitir descargar o cargar información mediante archivos JSON.

Registros

Los logs estructurados utilizan JSON para facilitar búsquedas, filtros y análisis.

Contenedores y nube

Las plataformas utilizan JSON para configuraciones, políticas, respuestas de servicios y descripciones de recursos.

Aplicaciones en marketing

JSON se encuentra presente en numerosos procesos de marketing, aunque el usuario final raramente lo observe.

Integración de CRM

Los sistemas pueden intercambiar contactos, empresas, oportunidades y actividades.

<syntaxhighlight lang="json"> {

 "contacto": {
   "nombre": "María López",
   "correo": "maria@ejemplo.com",
   "telefono": "5555555555",
   "origen": "Facebook Ads"
 }

} </syntaxhighlight>

Generación de leads

Los formularios pueden enviar la información al backend mediante JSON.

El payload puede incluir:

nombre;
correo;
teléfono;
producto;
campaña;
UTM;
consentimiento;
fecha;
página de origen.

Automatización de marketing

Los webhooks suelen enviar eventos JSON cuando ocurre una acción.

Ejemplo:

<syntaxhighlight lang="json"> {

 "event": "lead.created",
 "timestamp": "2026-07-14T15:30:00-06:00",
 "data": {
   "lead_id": "LEAD-5001",
   "source": "landing_page",
   "campaign": "verano_2026"
 }

} </syntaxhighlight>

El receptor puede utilizar esta información para:

crear un contacto;
enviar un correo;
asignar un vendedor;
añadir una etiqueta;
iniciar una secuencia;
notificar por Slack.

Catálogos de productos

Los productos pueden representarse mediante objetos JSON.

<syntaxhighlight lang="json"> {

 "sku": "BAT-LTH-001",
 "nombre": "Batería LTH",
 "precio": 2399,
 "moneda": "MXN",
 "existencia": 12,
 "compatibilidades": [
   "Audi A3",
   "Volkswagen Jetta",
   "SEAT León"
 ]

} </syntaxhighlight>

Comercio electrónico

Las tiendas intercambian información relacionada con:

productos;
variantes;
carritos;
pedidos;
pagos;
envíos;
cupones;
inventarios.

Analítica web

Las herramientas pueden registrar eventos estructurados:

<syntaxhighlight lang="json"> {

 "event": "generate_lead",
 "page_location": "https://www.ejemplo.com/cotizador",
 "lead_source": "organic",
 "value": 1500,
 "currency": "MXN"

} </syntaxhighlight>

La estructura exacta depende de la plataforma utilizada.

Data layer

Los gestores de etiquetas utilizan estructuras de JavaScript semejantes a JSON para comunicar eventos y variables.

Es importante distinguir que un objeto colocado directamente dentro de `dataLayer` es código JavaScript y puede incluir valores que un documento JSON estricto no admite.

Plataformas publicitarias

Las API de publicidad intercambian campañas, conjuntos, anuncios, presupuestos, resultados y audiencias mediante JSON.

Conversiones server-side

Los eventos enviados desde servidores hacia plataformas publicitarias suelen utilizar payloads JSON.

Estos eventos pueden incluir:

identificador;
fecha;
valor;
moneda;
productos;
datos de atribución;
señales de usuario protegidas.

El envío debe cumplir políticas de privacidad y tratamiento de datos.

Personalización

Una aplicación puede recibir reglas y segmentos mediante JSON:

<syntaxhighlight lang="json"> {

 "segment": "cliente_recurrente",
 "recommendations": [
   "producto_25",
   "producto_87"
 ],
 "banner": "fidelidad_2026"

} </syntaxhighlight>

Marketing de contenidos

Los gestores headless entregan artículos, categorías, autores y medios mediante API JSON.

SEO técnico

JSON puede utilizarse en herramientas de auditoría, rastreo, indexación y generación de sitemaps.

Datos estructurados

JSON-LD permite declarar entidades mediante vocabularios reconocidos.

Ejemplo de producto:

<syntaxhighlight lang="json"> {

 "@context": "https://schema.org",
 "@type": "Product",
 "name": "Batería automotriz",
 "sku": "BAT-001",
 "offers": {
   "@type": "Offer",
   "price": "1899.00",
   "priceCurrency": "MXN",
   "availability": "https://schema.org/InStock"
 }

} </syntaxhighlight>

Los datos estructurados deben coincidir con el contenido visible y cumplir las políticas de los buscadores.

SEO local

JSON-LD puede representar:

organizaciones;
negocios locales;
direcciones;
teléfonos;
horarios;
áreas de servicio;
coordenadas;
reseñas.

AEO y GEO

Las estructuras JSON pueden utilizarse para organizar preguntas, respuestas, entidades, citas y relaciones consumidas por sistemas de búsqueda y modelos generativos.

Paneles de marketing

Las aplicaciones analíticas consultan datos JSON para construir:

gráficas;
tablas;
filtros;
indicadores;
comparaciones;
alertas.

Encuestas e investigación

Las respuestas pueden almacenarse como documentos JSON para conservar preguntas, valores y metadatos.

Marketing conversacional

Chatbots y agentes intercambian mensajes, intenciones, contactos y estados mediante JSON.

Integración con WhatsApp

Los webhooks de plataformas de mensajería entregan notificaciones estructuradas relacionadas con:

mensajes;
estados;
contactos;
plantillas;
errores;
archivos.

Administración de campañas

Los parámetros y activos de una campaña pueden representarse mediante JSON:

<syntaxhighlight lang="json"> {

 "campaign": {
   "name": "Lanzamiento 2026",
   "channels": [
     "facebook",
     "instagram",
     "google"
   ],
   "start_date": "2026-08-01",
   "end_date": "2026-08-31",
   "budget": {
     "amount": 50000,
     "currency": "MXN"
   }
 }

} </syntaxhighlight>

Sistemas de recomendación

Los modelos pueden recibir eventos y devolver recomendaciones estructuradas.

Pruebas A/B

La asignación de variantes puede transmitirse mediante JSON:

<syntaxhighlight lang="json"> {

 "experiment": "hero_homepage",
 "variant": "B",
 "user_id": "USR-550"

} </syntaxhighlight>

Ventajas del concepto

Sintaxis compacta. Requiere menos caracteres que formatos basados en etiquetas para numerosas estructuras.

Legibilidad. Los documentos pequeños pueden inspeccionarse y editarse manualmente.

Independencia del lenguaje. Existen parsers y generadores para casi todos los lenguajes modernos.

Integración con JavaScript. Sus tipos se relacionan directamente con valores utilizados dentro de aplicaciones web.

Estructura jerárquica. Permite representar objetos y relaciones anidadas.

Flexibilidad. Puede representar numerosas clases de datos sin definir previamente un esquema obligatorio.

Interoperabilidad. Facilita comunicación entre sistemas heterogéneos.

Amplio ecosistema. Dispone de bibliotecas, validadores, editores y herramientas.

Compatibilidad con API. Es el formato predominante dentro de numerosas API web.

Procesamiento eficiente. Los parsers modernos pueden analizar grandes cantidades de información con rapidez.

Facilidad de depuración. Las respuestas pueden observarse directamente en navegadores y herramientas.

Compatibilidad con datos estructurados. JSON-LD permite añadir semántica y vocabularios.

Adecuación para automatización. Las plataformas pueden transformar propiedades y objetos dentro de flujos.

Extensibilidad. Las aplicaciones pueden añadir propiedades sin alterar la sintaxis base.

Compatibilidad con almacenamiento documental. Las estructuras pueden conservarse dentro de bases orientadas a documentos.

Separación entre datos y presentación. La misma información puede utilizarse en sitios, aplicaciones y sistemas externos.

Versionado sencillo. Los documentos pueden almacenarse y comparar cambios mediante control de versiones.

Limitaciones

Ausencia de comentarios. El formato estándar no permite anotaciones internas.

Tipos limitados. Carece de fechas, binarios, enteros de tamaños explícitos, decimales exactos y otros tipos.

Ausencia de esquema incorporado. Un documento válido puede contener datos incorrectos para la aplicación.

Precisión numérica variable. Diferentes lenguajes pueden interpretar números de forma distinta.

Nombres duplicados. Las implementaciones pueden procesarlos de manera inconsistente.

Sin referencias internas estándar. La estructura principal funciona como árbol y puede duplicar datos relacionados.

Anidamiento excesivo. Los documentos profundos resultan difíciles de leer y procesar.

Tamaño textual. Puede ser menos compacto que formatos binarios.

Falta de streaming natural. Un documento único grande puede necesitar cargarse completo antes de procesarse.

Orden de objetos no semántico. No debe utilizarse para representar secuencias.

Ausencia de espacios de nombres. Las propiedades pueden colisionar cuando se combinan vocabularios.

Semántica implícita. El formato no explica el significado de cada campo.

Dificultad para representar grafos. Los datos relacionados requieren identificadores, duplicación o formatos especializados.

Fragilidad manual. Una coma o comilla incorrecta invalida el documento.

No está diseñado para edición humana extensa. Los archivos grandes pueden resultar difíciles de mantener.

Expansión mediante Base64. Los datos binarios aumentan el tamaño.

Compatibilidad parcial de extensiones. JSON5, comentarios y comas finales no funcionan con parsers estrictos.

Riesgo de datos obsoletos. Los archivos pueden conservar estructuras antiguas sin validación.

Comparación textual engañosa. Dos documentos equivalentes pueden presentar diferencias en espacios u orden.

Consideraciones técnicas o estadísticas

Tamaño

El tamaño depende de:

cantidad de propiedades;
longitud de nombres;
profundidad;
repetición;
espacios;
datos binarios;
codificación.

La minificación elimina espacios y saltos no significativos.

La compresión HTTP como gzip o Brotli puede reducir considerablemente documentos con nombres repetidos.

Tiempo de parsing

El costo depende de:

tamaño;
profundidad;
implementación;
hardware;
asignación de memoria;
validación posterior.

Un documento enorme puede bloquear el hilo principal de una aplicación web.

Profundidad

Los documentos excesivamente anidados pueden:

agotar la pila;
consumir memoria;
ralentizar validadores;
provocar ataques de denegación de servicio.

Las aplicaciones deben establecer límites.

Números seguros

En JavaScript, `Number.MAX_SAFE_INTEGER` equivale a:

Los identificadores superiores deben transmitirse generalmente como cadenas cuando se necesita exactitud.

Decimales financieros

Los números de punto flotante pueden producir resultados como:

Las cantidades monetarias pueden representarse mediante:

enteros en unidades mínimas;
cadenas decimales;
tipos especializados;
objetos con importe y escala.

Ejemplo en centavos:

<syntaxhighlight lang="json"> {

 "amount": 199900,
 "currency": "MXN",
 "unit": "centavo"

} </syntaxhighlight>

Codificación

UTF-8 es la opción interoperable para intercambio abierto.

Un servidor debe utilizar el tipo de contenido apropiado:

<syntaxhighlight lang="text"> Content-Type: application/json </syntaxhighlight>

Compresión

JSON suele comprimirse bien debido a la repetición de nombres y estructuras.

Para payloads pequeños, el costo de compresión puede superar el ahorro.

Procesamiento incremental

Los documentos de gran tamaño pueden procesarse mediante parsers streaming o formatos secuenciales como JSON Lines y JSON Text Sequences.

Canonicalización

La comparación textual directa resulta insuficiente cuando el orden y los espacios cambian.

Los sistemas criptográficos necesitan reglas deterministas.

Validación

La validación puede incrementar latencia, aunque reduce errores y vulnerabilidades.

Los esquemas complejos con referencias dinámicas pueden requerir mayor procesamiento.

Caché

Las respuestas JSON pueden utilizar:

`Cache-Control`;
`ETag`;
`Last-Modified`;
CDN;
caché de aplicación.

Los datos personalizados y sensibles necesitan políticas restrictivas.

Paginación

Las respuestas grandes deben dividirse mediante:

páginas;
cursores;
límites;
streaming;
filtros.

Métricas operativas

Las aplicaciones pueden medir:

tamaño promedio;
tiempo de serialización;
tiempo de parsing;
errores sintácticos;
fallos de validación;
campos desconocidos;
versiones;
tasa de compresión;
latencia de API.

Seguridad

JSON es un formato de datos, aunque su procesamiento puede introducir riesgos.

Uso de eval

Los documentos nunca deben analizarse mediante `eval()`.

<syntaxhighlight lang="javascript"> const data = eval("(" + texto + ")"); </syntaxhighlight>

Esta práctica puede ejecutar código malicioso.

Debe utilizarse un parser específico:

<syntaxhighlight lang="javascript"> const data = JSON.parse(texto); </syntaxhighlight>

Inyección

Construir JSON mediante concatenación manual puede producir estructuras inválidas o manipulables.

Ejemplo inseguro:

<syntaxhighlight lang="javascript"> const texto = '{"nombre":"' + entradaUsuario + '"}'; </syntaxhighlight>

Debe utilizarse un serializador:

<syntaxhighlight lang="javascript"> const texto = JSON.stringify({

 nombre: entradaUsuario

}); </syntaxhighlight>

Cross-site scripting

Insertar JSON directamente dentro de HTML o scripts puede permitir cerrar etiquetas y ejecutar contenido.

Los datos deben codificarse según el contexto donde serán insertados.

Prototype pollution

Determinadas operaciones que fusionan objetos pueden procesar propiedades como `__proto__`, `constructor` o `prototype` de forma insegura.

El riesgo aparece en la lógica posterior al parsing y en bibliotecas de combinación.

Las mitigaciones incluyen:

validar nombres;
utilizar bibliotecas actualizadas;
crear objetos sin prototipo cuando corresponde;
evitar fusiones recursivas no controladas;
aplicar listas permitidas.

Denegación de servicio

Un atacante puede enviar:

documentos enormes;
cadenas muy largas;
arreglos masivos;
anidamiento profundo;
números extremos;
esquemas complejos.

Los sistemas deben limitar tamaño, profundidad, tiempo y recursos.

Nombres duplicados

Los parsers pueden interpretar de forma diferente un documento con claves repetidas.

Esto puede permitir que un sistema valide un valor y otro utilice uno diferente.

Los nombres duplicados deben rechazarse en contextos sensibles.

Validación insuficiente

Un parser confirma sintaxis, pero no verifica permisos ni reglas de negocio.

Los datos deben validarse después de analizarse.

Divulgación de información

Las respuestas pueden incluir accidentalmente:

contraseñas;
tokens;
claves;
datos personales;
campos internos;
trazas;
configuración.

Las aplicaciones deben definir explícitamente qué propiedades se serializan.

Mass assignment

Un backend puede asignar automáticamente todas las propiedades recibidas hacia un modelo interno.

Un atacante podría enviar:

<syntaxhighlight lang="json"> {

 "nombre": "Usuario",
 "rol": "administrador"

} </syntaxhighlight>

El servidor debe utilizar listas permitidas y aplicar autorización.

JSON Web Token

Un JWT firmado no se encuentra necesariamente cifrado.

La información del payload puede ser leída por quien posee el token.

No deben incluirse secretos ni datos sensibles innecesarios.

JSON hijacking

Las primeras aplicaciones web presentaron ataques relacionados con la inclusión de respuestas JSON mediante etiquetas de script.

Las mitigaciones modernas incluyen:

tipos de contenido correctos;
métodos HTTP apropiados;
autenticación;
SameSite;
CORS;
cabeceras de seguridad;
evitar respuestas sensibles accesibles mediante GET sin protección.

CORS

CORS regula qué orígenes pueden leer respuestas desde navegadores.

No sustituye autenticación ni autorización.

Datos estructurados maliciosos

El contenido JSON recibido desde sitios, documentos o herramientas puede incluir instrucciones destinadas a engañar agentes de inteligencia artificial.

Las aplicaciones agénticas deben tratar el contenido externo como datos y no como instrucciones autorizadas.

Herramientas y plataformas

JSON.parse(). Analiza JSON dentro de JavaScript.

JSON.stringify(). Serializa valores JavaScript.

jq. Herramienta de línea de comandos para consultar y transformar JSON.

JSONLint. Nombre utilizado por diferentes validadores de sintaxis.

JSON Schema. Ecosistema para describir y validar estructuras.

AJV. Validador JSON Schema para JavaScript.

Jackson. Biblioteca de procesamiento JSON para Java.

Gson. Biblioteca de Google para Java.

System.Text.Json. Biblioteca de .NET.

Newtonsoft.Json. Biblioteca JSON ampliamente utilizada en .NET.

json de Python. Módulo estándar para serialización y análisis.

serde_json. Biblioteca para Rust.

encoding/json. Paquete estándar de Go.

json_encode y json_decode. Funciones de PHP.

Postman. Permite enviar, inspeccionar y probar payloads JSON.

Insomnia. Cliente para API.

curl. Herramienta de línea de comandos para solicitudes HTTP.

OpenAPI. Especificación para describir API y esquemas de solicitudes y respuestas.

Swagger UI. Presenta documentación interactiva de API.

Visual Studio Code. Editor con validación, formateo y esquemas.

IntelliJ IDEA. Entorno con soporte para JSON y esquemas.

Sublime Text. Editor de texto con extensiones de JSON.

Prettier. Formateador capaz de normalizar documentos JSON.

ESLint. Puede analizar configuraciones y archivos relacionados con JavaScript.

PostgreSQL. Incluye tipos `json` y `jsonb`.

MySQL. Proporciona un tipo JSON y funciones de consulta.

MongoDB. Utiliza documentos BSON semejantes a JSON.

Elasticsearch. Utiliza API y documentos JSON.

Firebase. Intercambia datos mediante estructuras compatibles con JSON.

Supabase. Proporciona API y almacenamiento PostgreSQL con JSON.

n8n. Representa datos entre nodos mediante objetos estructurados.

Zapier. Procesa payloads y webhooks JSON.

Make. Mapea propiedades JSON entre módulos.

Google Tag Manager. Utiliza objetos JavaScript y estructuras de datos semejantes a JSON.

Google Rich Results Test. Comprueba determinados datos estructurados JSON-LD.

Schema Markup Validator. Valida vocabularios Schema.org.

Relación con otros conceptos

JavaScript. Lenguaje del cual JSON tomó parte de su sintaxis.

ECMAScript. Estándar que define JavaScript e incorpora funciones JSON.

Objeto de JavaScript. Estructura del lenguaje que posee más capacidades que JSON.

Serialización. Conversión de datos hacia un formato transportable.

Deserialización. Reconstrucción de valores desde un formato serializado.

API. Interfaz que utiliza frecuentemente JSON para intercambiar datos.

REST. Estilo arquitectónico cuyos servicios suelen utilizar JSON.

GraphQL. Lenguaje de consulta cuyas respuestas se representan habitualmente mediante JSON.

HTTP. Protocolo empleado para transportar documentos JSON.

Webhook. Solicitud automática que suele incluir un payload JSON.

Frontend. Capa que consume y presenta información JSON.

Backend. Capa que produce, valida y almacena información JSON.

Aplicación web. Sistema que utiliza JSON para comunicación y configuración.

Base de datos. Sistema que puede almacenar o producir documentos JSON.

NoSQL. Categoría de bases que incluye sistemas documentales.

MongoDB. Base documental basada en BSON.

PostgreSQL. Base relacional con soporte avanzado para JSON.

JSON Schema. Lenguaje de validación y documentación.

JSON-LD. Formato de datos enlazados basado en JSON.

Schema.org. Vocabulario utilizado frecuentemente mediante JSON-LD.

GeoJSON. Formato para datos geográficos.

JSON Pointer. Sintaxis para identificar valores.

JSON Patch. Formato para expresar modificaciones.

JSONPath. Lenguaje para seleccionar valores.

JSON Web Token. Formato de tokens basado en JSON.

XML. Formato textual jerárquico utilizado para intercambio y documentos.

YAML. Formato orientado a configuraciones y lectura humana.

CSV. Formato tabular delimitado.

BSON. Representación binaria con tipos adicionales.

MessagePack. Formato binario compacto.

Protocol Buffers. Sistema binario con esquemas.

RDF. Modelo de datos para información enlazada.

Linked Data. Método para relacionar datos mediante identificadores web.

SEO técnico. Campo donde JSON-LD desempeña una función importante.

Analítica web. Utiliza eventos y configuraciones estructuradas.

Automatización de marketing. Intercambia datos mediante JSON y webhooks.

CRM. Sistema que recibe y entrega contactos y oportunidades mediante API JSON.

Diferencias entre JSON y JavaScript

JavaScript es un lenguaje de programación.

JSON es un formato de datos.

JavaScript permite:

variables;
funciones;
clases;
operadores;
ciclos;
condiciones;
objetos con métodos;
comentarios;
tipos adicionales.

JSON permite únicamente objetos, arreglos, cadenas, números, booleanos y nulos.

En JavaScript, una propiedad puede escribirse sin comillas:

<syntaxhighlight lang="javascript"> {

 nombre: "Producto"

} </syntaxhighlight>

En JSON debe utilizar comillas dobles:

<syntaxhighlight lang="json"> {

 "nombre": "Producto"

} </syntaxhighlight>

Diferencias entre JSON y XML

JSON utiliza objetos y arreglos.

XML utiliza elementos, atributos y texto.

JSON:

<syntaxhighlight lang="json"> {

 "producto": {
   "nombre": "Batería",
   "precio": 1500
 }

} </syntaxhighlight>

XML:

 <nombre>Batería</nombre>
 <precio>1500</precio>

</producto> </syntaxhighlight>

JSON suele resultar más compacto para estructuras de aplicaciones.

XML ofrece funciones maduras relacionadas con:

espacios de nombres;
atributos;
contenido mixto;
validación;
transformaciones;
documentos.

La selección depende del problema y ecosistema.

Diferencias entre JSON y YAML

YAML se orienta a legibilidad humana y configuraciones.

Ejemplo YAML:

<syntaxhighlight lang="yaml"> producto:

 nombre: Batería
 precio: 1500

</syntaxhighlight>

YAML admite comentarios, referencias y una sintaxis más flexible.

Esa flexibilidad puede producir interpretaciones inesperadas y riesgos cuando se cargan objetos complejos mediante bibliotecas inseguras.

JSON presenta una gramática más pequeña y predecible para intercambio entre máquinas.

Diferencias entre JSON y CSV

CSV representa información tabular.

<syntaxhighlight lang="csv"> id,nombre,precio 1,Batería,1500 2,Cargador,650 </syntaxhighlight>

JSON permite estructuras jerárquicas y diferentes tipos.

CSV puede ser más compacto y práctico para tablas grandes.

JSON resulta más apropiado para objetos anidados, metadatos y API.

Diferencias entre JSON y JSON-LD

JSON define sintaxis.

JSON-LD añade convenciones para relacionar propiedades con vocabularios, identificadores y grafos.

Todo documento JSON-LD válido es JSON, aunque la mayoría de los documentos JSON carece de semántica JSON-LD.

Diferencias entre JSON y BSON

JSON es textual y utiliza un conjunto pequeño de tipos.

BSON es binario e incorpora tipos adicionales.

MongoDB utiliza BSON internamente y presenta los documentos mediante una notación semejante a JSON.

Diferencias entre JSON y Protocol Buffers

JSON puede utilizarse sin un esquema obligatorio y resulta legible por personas.

Protocol Buffers necesita definiciones de mensajes y utiliza una codificación binaria compacta.

Protocol Buffers puede ofrecer menor tamaño y mayor velocidad en sistemas de alto rendimiento.

JSON ofrece mayor facilidad para inspección, depuración e integración abierta.

Buenas prácticas

Utilizar un serializador. El documento debe generarse mediante bibliotecas y no mediante concatenación.

Utilizar un parser específico. Nunca debe analizarse con `eval()`.

Codificar en UTF-8. Mejora la interoperabilidad.

Enviar el Content-Type correcto. Debe utilizarse `application/json`.

Mantener nombres únicos. Los objetos no deben contener propiedades duplicadas.

Definir una convención de nombres. Las propiedades deben seguir un estilo consistente.

Utilizar nombres descriptivos. `customer_id` resulta más claro que `x1`.

Distinguir identificadores de números. Los identificadores pueden representarse como cadenas.

Definir fechas explícitamente. Se debe documentar formato y zona horaria.

Evitar decimales ambiguos. Las cantidades monetarias necesitan una estrategia precisa.

Definir el significado de null. La propiedad nula y la propiedad ausente pueden tener efectos diferentes.

Utilizar arreglos para secuencias. El orden de propiedades de un objeto no debe utilizarse como lógica.

Evitar anidamiento innecesario. Las estructuras profundas dificultan procesamiento.

Limitar tamaño y profundidad. Protege rendimiento y seguridad.

Validar la sintaxis. Los documentos mal formados deben rechazarse.

Validar la estructura. JSON Schema puede utilizarse para comprobar contratos.

Rechazar propiedades inesperadas cuando corresponda. Reduce errores y mass assignment.

Versionar los contratos. Los consumidores deben conocer cambios incompatibles.

Mantener compatibilidad retroactiva. Añadir propiedades opcionales suele resultar menos disruptivo que cambiar tipos.

Proporcionar ejemplos reales. La documentación necesita payloads válidos.

Documentar errores. Las respuestas deben utilizar una estructura uniforme.

Paginar grandes colecciones. Evita respuestas excesivas.

Comprimir respuestas grandes. Debe evaluarse según tamaño y carga.

Aplicar caché adecuada. Los datos sensibles no deben almacenarse públicamente.

Separar archivos binarios. Conviene utilizar almacenamiento o multipart para archivos grandes.

No incluir secretos. Las respuestas deben contener solamente campos necesarios.

Utilizar listas permitidas. El backend debe decidir qué propiedades acepta y devuelve.

Registrar fallos de parsing. Facilita detectar integraciones defectuosas.

Probar en distintos lenguajes. La interoperabilidad numérica y Unicode debe comprobarse.

Canonicalizar antes de firmar. Los sistemas criptográficos necesitan una representación determinista.

Mantener JSON-LD consistente con la página. Los datos estructurados deben representar contenido visible y verdadero.

Errores comunes

Confundir un objeto JavaScript con JSON. La sintaxis admite características diferentes.

Utilizar comillas simples. JSON exige comillas dobles.

Omitir comillas en las claves. Los nombres deben ser cadenas.

Añadir comas finales. Los parsers estrictos las rechazan.

Incluir comentarios. El estándar no los admite.

Utilizar undefined. JSON carece de este valor.

Utilizar NaN o Infinity. No forman parte de la sintaxis.

Representar fechas sin documentarlas. La interpretación puede variar.

Enviar enteros grandes como números. Pueden perder precisión.

Usar números de punto flotante para dinero sin estrategia. Puede producir errores.

Depender del orden de las propiedades. Los objetos carecen de orden semántico.

Permitir claves duplicadas. Las implementaciones pueden utilizar valores diferentes.

Construir texto mediante concatenación. Aumenta errores e inyecciones.

No escapar cadenas. Las comillas y saltos pueden invalidar el documento.

Analizar mediante eval. Permite ejecución de código.

Confiar únicamente en JSON.parse. La sintaxis válida no garantiza datos seguros.

Aceptar todas las propiedades. Puede permitir mass assignment.

Devolver modelos completos de base de datos. Puede exponer campos privados.

Incluir archivos grandes mediante Base64. Incrementa tamaño y memoria.

Enviar respuestas sin límites. Las colecciones pueden consumir demasiados recursos.

Utilizar JSON para contenido tabular masivo sin evaluar alternativas. CSV o formatos columnares pueden resultar más eficientes.

Editar manualmente archivos extensos. Aumenta el riesgo de errores sintácticos.

Utilizar extensiones no estándar sin declararlas. Un parser estricto rechazará JSON5 o comentarios.

No declarar la versión de un esquema. Los validadores pueden interpretar reglas diferentes.

Firmar texto JSON sin canonicalización. Los espacios y orden pueden cambiar la firma.

Confundir JWT con cifrado. El payload puede ser visible.

Insertar JSON dentro de HTML sin codificación. Puede producir XSS.

Guardar datos personales innecesarios en logs JSON. Amplía exposición y obligaciones.

Usar null para múltiples significados. Puede representar desconocido, eliminado, vacío o no aplicable y generar ambigüedad.

Cambiar el tipo de una propiedad. Los consumidores existentes pueden dejar de funcionar.

Desafíos éticos y organizacionales

Privacidad. JSON facilita mover grandes cantidades de datos personales entre plataformas.

Minimización. Las integraciones pueden enviar más campos de los necesarios.

Consentimiento. Los datos de marketing deben utilizarse conforme a finalidades autorizadas.

Trazabilidad. Las organizaciones necesitan identificar qué sistema produjo y recibió cada payload.

Propiedad de datos. Debe definirse quién controla, modifica y elimina la información.

Calidad. Los errores estructurados pueden propagarse entre numerosos sistemas.

Dependencia de proveedores. Los formatos de API pueden vincular procesos con plataformas específicas.

Interoperabilidad. Las extensiones propietarias reducen portabilidad.

Seguridad. Una respuesta puede exponer datos internos aunque sea sintácticamente correcta.

Retención. Los logs, respaldos y eventos JSON pueden conservar datos durante periodos excesivos.

Datos sensibles en automatizaciones. Las plataformas intermedias pueden recibir información confidencial.

Decisiones automatizadas. Los payloads pueden alimentar modelos y reglas que afectan oportunidades o precios.

Sesgos de clasificación. Las etiquetas transmitidas pueden contener inferencias incorrectas.

Derechos de usuarios. La organización debe poder localizar, exportar y eliminar información distribuida.

Gobernanza de esquemas. Los cambios necesitan responsables, revisión y comunicación.

Documentación. Los contratos no documentados generan dependencia del conocimiento informal.

Shadow IT. Los equipos pueden crear webhooks y automatizaciones sin supervisión.

Sostenibilidad. Payloads excesivos aumentan transferencia, almacenamiento y consumo.

Una política organizacional puede incluir:

catálogo de API;
propietarios de esquemas;
clasificación de datos;
convenciones de nombres;
límites de tamaño;
validación;
versionado;
retención;
anonimización;
cifrado;
auditoría;
respuesta a incidentes;
retiro de integraciones.

Impacto actual

JSON se ha convertido en una infraestructura fundamental de la economía digital.

Las aplicaciones web utilizan JSON para cargar información sin reemplazar páginas completas. Las aplicaciones móviles consumen API JSON para mostrar contenidos y operaciones. Los servicios en la nube utilizan JSON para configurar recursos y devolver resultados.

Las plataformas de marketing reciben y entregan campañas, audiencias, conversiones y métricas mediante estructuras JSON.

Los sistemas de automatización permiten mapear propiedades entre CRM, formularios, hojas de cálculo, mensajería y comercio electrónico.

La expansión de arquitecturas headless ha aumentado su importancia. Un gestor de contenidos puede entregar artículos mediante JSON hacia sitios, aplicaciones, pantallas y asistentes.

JSON-LD se ha convertido en una de las formas principales de publicar datos estructurados para motores de búsqueda.

La inteligencia artificial utiliza JSON para solicitar herramientas y producir respuestas estructuradas. Los agentes pueden generar argumentos, ejecutar funciones y recibir resultados mediante objetos JSON.

Los modelos generativos también producen documentos mal formados o incompatibles, por lo que las aplicaciones necesitan validación, esquemas y reintentos controlados.

La popularidad de JSON ha generado una amplia variedad de extensiones y perfiles. Esta diversidad resuelve necesidades específicas y puede reducir interoperabilidad cuando los sistemas asumen capacidades no estándar.

Su éxito se debe parcialmente a una sintaxis suficientemente pequeña para ser implementada en casi cualquier entorno.

La facilidad para generar documentos no elimina la necesidad de diseñar contratos. La calidad de una integración depende de nombres, semántica, tipos, versionado, validación y seguridad.

En marketing, JSON funciona como una capa invisible que conecta captación, ventas, publicidad, contenidos, analítica y automatización.

Futuro y tendencias

Mayor uso en inteligencia artificial. Los modelos producirán salidas estructuradas compatibles con esquemas.

Llamadas a herramientas. Los agentes utilizarán JSON para seleccionar funciones y proporcionar argumentos.

Validación nativa. Las plataformas integrarán esquemas y restricciones directamente en la generación.

Contratos generados automáticamente. Los sistemas crearán JSON Schema y OpenAPI a partir de código y ejemplos.

JSON Schema más estable. El proyecto trabaja hacia procesos de evolución con mayor compatibilidad.

Canonicalización. Las firmas, credenciales y sistemas verificables aumentarán el uso de representaciones deterministas.

Datos enlazados. JSON-LD continuará conectando información con vocabularios semánticos.

JSON-LD 1.2. El W3C trabaja en una nueva versión con mejoras de interoperabilidad y procesamiento.

Procesamiento en streaming. Los grandes conjuntos utilizarán JSON Lines, secuencias y parsers incrementales.

Formatos binarios complementarios. CBOR, MessagePack y Protocol Buffers se utilizarán cuando el tamaño o rendimiento resulte crítico.

Bases multimodelo. Los sistemas relacionales, documentales y analíticos ampliarán sus funciones JSON.

Consultas estandarizadas. JSONPath proporcionará una sintaxis común para seleccionar valores.

Tipado y generación de código. Los esquemas producirán clases, validadores y documentación.

Eventos empresariales. Las arquitecturas orientadas a eventos utilizarán contratos JSON gobernados.

Privacidad automatizada. Las herramientas detectarán campos sensibles dentro de payloads.

Observabilidad estructurada. Los logs JSON facilitarán análisis mediante agentes y plataformas.

Interoperabilidad de agentes. Protocolos como Model Context Protocol utilizarán estructuras JSON-RPC o formatos relacionados.

Datos estructurados para buscadores generativos. JSON-LD mantendrá relevancia dentro de SEO, AEO y GEO.

Webhooks más seguros. Las firmas, idempotencia y esquemas se convertirán en requisitos comunes.

Evolución de API. Las organizaciones utilizarán compatibilidad semántica y pruebas automáticas de contratos.

Interfaces no-code. Más personas manipularán estructuras JSON mediante editores visuales.

Gobernanza de datos. Los esquemas se integrarán con catálogos, linaje y políticas.

Procesamiento local. Navegadores y dispositivos analizarán JSON dentro de aplicaciones offline y modelos locales.

Reducción de payloads. Las organizaciones controlarán campos innecesarios por costos, velocidad y privacidad.

Seguridad orientada a estructura. Los validadores aplicarán límites de profundidad, tamaño y propiedades.

Mayor distinción entre sintaxis y semántica. Los equipos comprenderán que JSON válido no equivale a información correcta.

Véase también

Referencias

Bibliografía

Bray, Tim. The JavaScript Object Notation (JSON) Data Interchange Format. IETF, 2017.
Crockford, Douglas. JavaScript: The Good Parts. O’Reilly Media.
Ecma International. ECMA-404: The JSON Data Interchange Syntax. Segunda edición, 2017.
Marrs, Tom. JSON at Work: Practical Data Integration for the Web. O’Reilly Media.
Pezoa, Felipe; Reutter, Juan L.; Suárez, Fernando; Ugarte, Martín; Vrgoč, Domagoj. Foundations of JSON Schema. International World Wide Web Conference, 2016.
Bourhis, Pierre; Reutter, Juan L.; Suárez, Fernando; Vrgoč, Domagoj. JSON: Data Model, Query Languages and Schema Specification. 2017.
Attouche, Lyes; Baazizi, Mohamed-Amine; Colazzo, Dario; Ghelli, Giorgio; Sartiani, Carlo; Scherzinger, Stefanie. Validation of Modern JSON Schema: Formalization and Complexity. 2023.
Mozilla. MDN Web Docs: Working with JSON.
JSON Schema Project. Understanding JSON Schema.
World Wide Web Consortium. JSON-LD 1.1.
OpenAPI Initiative. OpenAPI Specification.
OWASP Foundation. API Security Top 10.
RFC Editor. JSON Pointer, JSON Patch, JSON Merge Patch and JSONPath Specifications.