Generador de JSON de prueba

Por qué «test1» no sirve para probar

Un JSON de prueba con {"nombre": "test1", "email": "a@a.com"} sirve para que el código compile, no para probar nada. En cuanto una pantalla pinta esos datos, o en cuanto alguien los mira, se nota:

• Las columnas quedan raras, porque todos los valores miden lo mismo. Nunca descubres que el diseño se rompe con un apellido largo.
• No pruebas la codificación: sin tildes ni eñes, un problema de UTF-8 pasa desapercibido hasta producción.
• No pruebas la ordenación ni la búsqueda: con «test1, test2, test3» cualquier orden parece correcto.
• Y no detectas los tipos mal elegidos: un DNI que empieza por cero guardado como número, un teléfono con el signo más, un identificador de 20 dígitos.

Por eso este generador rellena cada campo según su tipo: si dices que un campo es un DNI, recibes ocho dígitos que parecen un DNI; si dices que es un nombre, recibes un nombre peruano con dos apellidos y su longitud real.

Cinco cosas que no son JSON válido, y casi lo parecen

JSON es un formato mucho más estricto que el objeto literal de JavaScript, y esa diferencia produce fallos difíciles de ver:

// 1. Coma final: válida en JavaScript, INVÁLIDA en JSON
{ "a": 1, "b": 2, }

// 2. NaN e Infinity no existen en JSON
{ "valor": NaN }          // JSON.stringify los convierte en null

// 3. Comillas simples: no
{ 'a': 1 }

// 4. Comentarios: no existen en JSON
{ "a": 1 }  // esto rompe el parseo

// 5. Enteros grandes: válidos, pero pierden precisión al leerlos
JSON.parse('{"id": 9007199254740993}').id   // 9007199254740992 ← cambió

La quinta es la peligrosa, porque no da ningún error. Si tu API devuelve identificadores grandes como número, los últimos dígitos pueden cambiar en el camino. La solución es enviarlos como cadena: {"id": "9007199254740993"}. Es lo que hacen las API que manejan identificadores largos, y por eso lo hacen.

JSON no tiene tipo fecha

Es una de las carencias más sentidas del formato: no existe un tipo fecha. Todo lo que hay son cadenas y números, así que cada equipo elige y ahí empiezan los desencuentros:

La recomendación es siempre la misma: ISO 8601 con zona horaria explícita. Es legible, ordena alfabéticamente igual que cronológicamente, y no admite interpretaciones.

Para qué se usa un JSON de prueba

• Sembrar una base de datos de desarrollo sin copiar datos reales de producción, que es arriesgado y en muchos casos ilegal según la normativa de protección de datos.
• Alimentar un mock server mientras el backend no existe, para que el equipo de front no espere.
• Documentar un contrato de API con ejemplos parecidos a lo que llegará de verdad.
• Probar el rendimiento de una tabla con cien registros en lugar de tres: ahí aparecen los problemas de paginación, de orden y de maquetación.
• Comprobar la codificación de punta a punta: genera cien registros con tildes y eñes, guárdalos, vuelve a leerlos y compara. Si algo vuelve distinto, hay un problema de UTF-8 en algún punto de la cadena.

Se genera en tu navegador

La estructura que defines y los datos que salen no viajan a ningún servidor: todo se calcula en tu equipo. Si necesitas acompañar el JSON con respuestas de API completas —con su código de estado y sus cabeceras—, tienes el generador de respuestas HTTP mock.