Tipos de Datos JSON Explicados: Los Seis Tipos de Valor de RFC 8259

Introducción: Todo Valor JSON Es de Uno de Exactamente Seis Tipos

Si preguntas a la mayoría de desarrolladores cuántos tipos de datos tiene JSON, oirás respuestas variadas. La especificación es inequívoca: un valor JSON es de uno de exactamente seis tipos. Cuatro de ellos son primitivos — cadena, número, booleano y null — y dos son contenedores estructurados que albergan otros valores — objeto y array. No hay nada más. No hay tipo fecha, ni distinción entero-frente-a-decimal, ni undefined, ni binario. Todo lo que codifiques alguna vez en JSON se construye anidando estos seis tipos unos dentro de otros.

Conocer la lista exacta importa porque una gran parte de los problemas de "JSON inválido" y "la API rechazó mi petición" provienen de poner un valor en el tipo equivocado: entrecomillar un número que debería ser numérico, escribir un booleano con mayúscula inicial, usar undefined donde solo existe null, o envolver un valor en comillas simples. Esta guía es una referencia precisa y basada en ejemplos de los seis tipos de valor definidos por la RFC 8259, el estándar de Internet vigente para JSON. Para cada tipo mostramos qué aspecto tiene, qué es válido, qué no lo es, y dónde trazan la línea los analizadores estrictos y las APIs. Pega cualquier fragmento en nuestro formateador y validador JSON para ver cada regla aplicada contra el carácter exacto que la rompe.

Los Seis Tipos de Valor de un Vistazo

La RFC 8259, publicada en diciembre de 2017 y designada STD 90, define un valor JSON con una única regla breve: un valor debe ser un objeto, un array, un número, una cadena o uno de los tres nombres literales true, false y null. Eso da los seis tipos en los que toda implementación coincide:

• objeto — un conjunto no ordenado de pares nombre/valor envuelto en { }.
• array — una lista ordenada de valores envuelta en [ ].
• cadena — texto entre comillas dobles.
• número — un literal numérico en notación decimal.
• booleano — el literal true o false.
• null — el literal null, que representa la ausencia intencionada de valor.

Un documento JSON completo, a menudo llamado el "texto", es él mismo simplemente un único valor con espacio en blanco opcional alrededor. Ese valor suele ser un objeto o un array, pero un 42 suelto, una "hola" suelta o un true suelto también son documentos JSON completos y válidos según la RFC 8259. Herramientas más antiguas a veces insistían en que el nivel superior fuera un objeto o un array, pero el estándar vigente no lo exige.

Objetos y Arrays: Los Dos Tipos Estructurados

Los dos tipos contenedor son lo que permite a JSON representar cualquier cosa, desde un registro de usuario hasta una respuesta de API profundamente anidada. Un objeto es una colección no ordenada de pares nombre/valor, donde cada nombre es una cadena y cada valor es cualquiera de los seis tipos. Un array es una secuencia ordenada de valores, y esos valores no tienen por qué compartir tipo — [1, "dos", true, null] es JSON perfectamente válido. Ambos contenedores pueden estar vacíos ({} y []) y ambos pueden anidarse a cualquier profundidad.

La distinción clave que hay que interiorizar es que los objetos son no ordenados y con clave, mientras que los arrays son ordenados e indexados. Diriges un valor de un objeto por su nombre y uno de un array por su posición. Como los objetos son no ordenados por definición, nunca debes depender del orden de las claves para la corrección aunque muchos analizadores conserven el orden de inserción. Los nombres de objeto son el único lugar donde JSON fuerza un tipo concreto: un nombre es siempre una cadena, así que { 42: "x" } es inválido y debe escribirse { "42": "x" }. Para el conjunto completo de reglas de objetos — nombres entre comillas, los seis caracteres estructurales, comas finales y claves duplicadas — consulta nuestra referencia complementaria sobre la sintaxis de objetos JSON según RFC 8259.

Cadenas: Texto Entre Comillas Dobles

Una cadena JSON es una secuencia de caracteres Unicode envuelta en comillas dobles — el carácter " en el punto de código U+0022. Ningún otro delimitador funciona: las comillas simples, los acentos graves y las comillas tipográficas curvas no son delimitadores de cadena en JSON. Esta única regla evita toda una familia de errores.

Válido: { "message": "hola mundo" }

Inválido — comillas simples: { "message": 'hola mundo' }

Ciertos caracteres dentro de una cadena deben escaparse con una barra invertida. Una comilla doble literal se escribe \" y una barra invertida se escribe \\. Los caracteres de control (de U+0000 a U+001F) nunca pueden aparecer literalmente; se escriben con escapes como \n para un salto de línea o \t para un tabulador, y cualquier carácter puede escribirse con un escape \u y cuatro dígitos hexadecimales. Escribir un salto de línea real y sin escapar dentro de las comillas hace inválido el documento. Las cadenas son además donde viven las fechas, las marcas de tiempo y otros valores ricos, porque JSON no tiene un tipo nativo para ellos: una marca de tiempo ISO 8601 como "2026-07-21T09:30:00Z" es simplemente una cadena, y ambos extremos del cable deben ponerse de acuerdo sobre cómo interpretarla. Las reglas completas de entrecomillado y escape se cubren en nuestra guía de reglas de escape de cadenas JSON.

Números: Decimales, Finitos y Sin Ceros a la Izquierda

El tipo número de JSON está especificado con más rigor de lo que la gente espera, y es donde se esconden bugs sutiles. La RFC 8259 define un número solo en notación decimal, compuesto por un signo menos opcional, una parte entera, una parte fraccionaria opcional introducida por un punto decimal y un exponente opcional introducido por e o E. No hay un tipo entero separado ni un tipo decimal separado — hay un único tipo número, y 42 y 42.0 son ambos simplemente números.

Varias restricciones se derivan directamente de la gramática:

• Sin ceros a la izquierda. 0 es correcto y 0.5 es correcto, pero 007 y 01 son inválidos.
• No se permite un punto decimal inicial. Escribe 0.5, no .5. Un punto final como 5. también es inválido.
• Sin signo más en el número completo. +5 es inválido; escribe 5. El más solo se permite dentro de un exponente, como en 5e+3.
• Se permiten exponentes. 1.5e10, 2E-8 y 6.022e23 son todos números válidos.
• Sin valores no finitos. NaN, Infinity y -Infinity no son números JSON ni son JSON válido en absoluto, aunque JavaScript los produzca en tiempo de ejecución.
• Sin hexadecimal, octal ni separadores de miles. 0x1F, 0o17 y 1_000 son todos inválidos.

Una advertencia práctica sobre la precisión: la RFC 8259 no impone un rango o precisión numérica concretos, pero señala que las implementaciones usan ampliamente coma flotante de doble precisión IEEE 754, que solo puede representar con seguridad enteros hasta 2 elevado a 53. Los números mayores que eso — identificadores largos de base de datos, por ejemplo — pueden perder precisión al analizarse. La solución habitual es transmitir esos identificadores como cadenas, manteniéndolos exactos de extremo a extremo.

Booleanos y null: Los Tres Nombres Literales

El tipo booleano tiene exactamente dos valores, escritos como los literales desnudos true y false. Van siempre en minúsculas y nunca entre comillas. True, FALSE y "true" no son booleanos JSON: los dos primeros no son JSON válido en absoluto, y el tercero es una cadena que solo parece un booleano. Esa distinción muerde fuerte cuando una API espera una bandera booleana y recibe la cadena "false", que muchos lenguajes tratan como verdadera — la petición hace en silencio lo contrario de lo que se pretendía.

El tipo null tiene un único valor, el literal en minúsculas null. Representa la ausencia intencionada de un valor. JSON no tiene undefined, ni None, ni nil — esos pertenecen a lenguajes de programación concretos. Si serializas un objeto JavaScript con una propiedad undefined, los serializadores estándar eliminan la propiedad por completo en lugar de emitir undefined, porque undefined no es un valor JSON. Cuando realmente quieres decir "este campo existe pero no tiene valor", la codificación correcta es null. Ten en cuenta que un campo puesto a null y un campo ausente son dos estados diferentes, y las APIs bien diseñadas los tratan de forma distinta.

Errores de Tipo Comunes que Rompen Payloads Reales

Casi todo bug de tipo en JSON es una de un puñado de confusiones entre un valor y su parecido en forma de cadena, o una costumbre arrastrada desde un lenguaje de programación. Estos son los que con más frecuencia hacen que un servidor estricto rechace una petición o que un analizador lance un error:

• Entrecomillar un número: { "age": "30" } cuando la API espera { "age": 30 }. Ambos son JSON válido, pero son tipos distintos, y un esquema que exige un número rechazará la cadena.
• Entrecomillar un booleano: { "active": "true" } en vez de { "active": true }. La cadena es verdadera en muchos lenguajes, invirtiendo tu lógica.
• Literales con mayúscula: True, False o Null. Los literales JSON van solo en minúsculas, y las formas con mayúscula no son JSON válido.
• Usar undefined o NaN: ambos vienen de JavaScript y ninguno es un valor JSON. Usa null para un valor ausente y un número decimal real donde se requiere un número.
• Comillas simples: { 'name': 'Ada' }. Las cadenas y los nombres JSON requieren comillas dobles.
• Números con cero inicial o punto suelto: 007, .5, 5. y +5 incumplen todos la gramática de números.

Por Qué Importa el Tipado Estricto Cuando las APIs Consumen JSON

El sistema de tipos de JSON es pequeño, pero los sistemas que consumen JSON no son indulgentes con él. Cuando un cuerpo de petición llega a un servidor, normalmente se valida contra un esquema o se deserializa en una estructura tipada — un struct en Go, una clase en Java, un modelo en Python o TypeScript. En esa frontera, 30 y "30" no son intercambiables. Un campo tipado como entero rechazará la cadena; un campo tipado como booleano rechazará "true". El desajuste aparece como un error 400 en el mejor caso y como una corrupción de datos silenciosa en el peor, cuando un analizador permisivo coacciona el valor de una forma que no pretendías.

Por eso la disciplina de tipos en el lado que produce da frutos directos. Emite números como números, booleanos como true y false desnudos, y valores ausentes como null, y el esquema consumidor valida limpiamente. La herramienta que formaliza estas expectativas es JSON Schema, que te permite declarar que una propiedad debe ser de tipo integer, string o boolean y rechazar cualquier otra cosa antes de que se ejecute el código de tu aplicación. Puedes comprobar un documento contra un contrato con nuestro formateador JSON para la sintaxis y un validador de esquema para los tipos — la validez sintáctica es solo la primera puerta, y los tipos correctos son la segunda.

Ejemplo Trabajado: Los Seis Tipos en un Documento

Aquí tienes un único documento válido que ejercita cada uno de los seis tipos de valor a la vez — un objeto arriba, un array de objetos dentro, cadenas, números con y sin exponentes, ambos booleanos y un null:

{
"id": 1001,
"label": "Informe trimestral",
"published": true,
"archived": false,
"reviewer": null,
"score": 9.5,
"views": 1200,
"ratio": 6.4e-2,
"tags": ["finanzas", "q3"],
"authors": [
{ "name": "Ada", "lead": true },
{ "name": "Grace", "lead": false }
]
}

Cada valor de arriba tiene un tipo inequívoco: id, score, views y ratio son números; label y las entradas de etiqueta son cadenas; published, archived y lead son booleanos; reviewer es null; tags y authors son arrays; y el conjunto entero más cada entrada de autor son objetos. Cambia cualquier valor por su parecido de tipo equivocado — entrecomilla un número, pon en mayúscula un booleano, sustituye null por undefined — y un validador estricto marcará exactamente ese valor.

Valida Tipos y Sintaxis con el Formateador JSON

Nuestro formateador y validador JSON es la forma más rápida de confirmar todo lo de esta guía. Pega un documento y da formato bonito al JSON válido, señala el carácter exacto donde falla el JSON inválido y resalta los errores de tipo anteriores — nombres sin comillas, comillas simples, literales en mayúscula y números mal formados. Como se ejecuta enteramente en tu navegador, ningún dato sale nunca de tu máquina, así que es seguro para payloads y credenciales de producción. Una vez limpia la sintaxis, pasa a las dos referencias que profundizan en los tipos más traicioneros: la sintaxis de objetos JSON para el contenedor objeto y las reglas de escape de cadenas JSON para el tipo cadena. Juntas cubren los rincones de JSON donde los datos de apariencia válida resultan con más frecuencia ser del tipo equivocado.