Escapar / Desescapar JSON
Escapa los caracteres especiales de una cadena para integrarla con seguridad en JSON, o desescapa una cadena JSON a texto plano.
Cómo funciona
- Pega tu cadena: introduce el texto a escapar, puede ser texto plano que contiene comillas, saltos de línea, barras invertidas o cualquier otro carácter especial.
- Elige escapar o desescapar: selecciona si quieres escapar texto para incrustarlo en JSON, o desescapar una cadena JSON a texto legible.
- Copia el resultado: la salida escapada o desescapada aparece al instante. Cópiala para usarla en tu código o tus datos.
¿Por qué usar el escape JSON?
Las cadenas JSON tienen reglas de escape estrictas, las comillas dobles deben pasar a \", los saltos de línea a \n, las barras invertidas a \\ y las tabulaciones a \t. No escapar correctamente estos caracteres provoca errores de análisis JSON que rompen API, archivos de configuración y pipelines de datos. Esta herramienta gestiona automáticamente todo el escape y desescape, eliminando el buscar-reemplazar manual y evitando bugs sutiles debidos a secuencias de escape omitidas.
Funcionalidades
- Cobertura de escape completa: gestiona comillas, barras invertidas, saltos de línea, tabulaciones, retornos de carro y secuencias de escape Unicode.
- Bidireccional: tanto escapar (texto → cadena JSON) como desescapar (cadena JSON → texto) en una sola herramienta.
- Resultados al instante: la salida se actualiza a medida que escribes, sin retraso.
- Copiar al portapapeles: copia con un clic del resultado escapado o desescapado.
- Privacidad ante todo: todo el procesamiento se hace localmente, las cadenas sensibles nunca salen de tu dispositivo.
Preguntas frecuentes
¿Qué caracteres gestiona el escape JSON?
JSON exige el escape de: comillas dobles ("), barra invertida (\), barra (/), salto de línea (\n), retorno de carro (\r), tabulación (\t), salto de página (\f), retroceso (\b) y caracteres Unicode por encima de U+FFFF. Esta herramienta los gestiona todos.
¿Por qué mi error de análisis JSON se debe al escape?
Las causas habituales incluyen comillas dobles sin escapar dentro de un valor de cadena, saltos de línea literales en una cadena (deben ser \n) y barras invertidas sin escapar. Pega tu cadena rota aquí para escaparla correctamente.
¿Esto incluye las comillas que envuelven?
Por defecto, la herramienta escapa el contenido sin englobar con comillas, para que puedas pegar el resultado en tu cadena JSON. Activa la opción «Incluir las comillas» si quieres que la salida vaya entre comillas dobles.
La especificación JSON String, en una tabla
RFC 8259 (diciembre de 2017, por Tim Bray) es el estándar JSON actual, reemplazando RFC 7159 y el original RFC 4627. La sección 7 de la spec lista exactamente qué caracteres DEBEN escaparse dentro de un literal de cadena:
| Carácter | Escape | Punto de código | Significado |
|---|---|---|---|
" | \" | U+0022 | comilla (termina la cadena) |
\ | \\ | U+005C | barra invertida (inicia un escape) |
\b | \b | U+0008 | retroceso |
\f | \f | U+000C | salto de página |
\n | \n | U+000A | salto de línea (LF) |
\r | \r | U+000D | retorno de carro (CR) |
\t | \t | U+0009 | tabulación |
/ | \/ | U+002F | barra (opcional, pero útil para embedding HTML) |
| control | \uXXXX | U+0000–U+001F | cualquier carácter de control C0 no cubierto arriba |
Reglas equivalentes están en ECMA-404 (2da edición, diciembre de 2017), mantenido en sincronía con la spec IETF. JSON no tiene escapes octales (\012) o hexadecimales (\x41), esos son solo JavaScript; JSON solo soporta los ocho escapes nombrados arriba más \uXXXX.
El escape \uXXXX y la trampa de la pareja suplente
Las secuencias \uXXXX de JSON codifican unidades de código UTF-16, no puntos de código Unicode. Eso importa para emoji y caracteres del plano suplementario. Un solo emoji como 😀 (U+1F600) se escapa no como \u1F600 (eso no es siquiera una forma legal de cuatro dígitos hexadecimales), sino como una pareja suplente: \uD83D\uDE00, dos escapes consecutivos codificando las suplentes alta y baja. El rango suplente alto es U+D800–U+DBFF; el bajo es U+DC00–U+DFFF; juntos cubren U+10000 a U+10FFFF (los planos suplementarios).
Esta es la fuente más común de bugs de escape de emoji. La sección 7 de RFC 8259 dice explícitamente: «Para escapar un carácter extendido que no está en el plano multilingüe básico, el carácter se representa como una secuencia de 12 caracteres, codificando la pareja suplente UTF-16.» Un emoji familia de cuatro como 👨👩👧👦, que es técnicamente cuatro emoji base más tres uniones de ancho cero, se escapa como 30+ caracteres en una cadena JSON. El conteo de bytes se infla en consecuencia: 25 bytes UTF-8 sin procesar, ~58 bytes después del escape JSON.
JSON dentro de HTML, URL, SQL y CSV
El escape JSON por sí solo no es suficiente cuando el JSON está incrustado en otro formato. Cada contexto agrega su propia capa.
JSON dentro de HTML. La trampa clásica es <script>const data = {{ payload | json }};</script> cuando el payload contiene la subcadena literal </script>. El parser HTML cierra la etiqueta script a mitad de cadena y el resto del JSON se renderiza como texto visible en la página. La solución es el escape opcional \/: <\/script> es JSON válido y HTML seguro. La hoja de cross-site scripting de OWASP recomienda escapar siempre <, >, & y ' en JSON destinado a embedding HTML.
JSON dentro de una cadena de consulta URL. Dos capas: primero escapar JSON, luego percent-encoding. {"name":"Bob"} se convierte en %7B%22name%22%3A%22Bob%22%7D. Olvidar el percent-encoding es la causa nº 1 de bugs de JSON-en-URL mal formados.
JSON dentro de SQL. Almacenado en una columna PostgreSQL jsonb el valor se parsea nativamente, no se necesita escape adicional. Pero JSON incrustado en un literal de cadena SQL (INSERT INTO t (data) VALUES ('{"key":"value"}')) necesita escape de cadena SQL encima de JSON: comillas simples duplicadas (''), o mejor, usa consultas parametrizadas.
JSON dentro de celdas CSV. El comillado de CSV difiere del de JSON (CSV usa comillas duplicadas "", no secuencias con barra invertida). Incrustar JSON en una celda CSV necesita ambas capas: escapar JSON la cadena, luego escapar CSV el resultado (envolver en "...", doblar cualquier " interno).
APIs de tiempo de ejecución en varios lenguajes
| Lenguaje | Codificar | Decodificar | Notas |
|---|---|---|---|
| JavaScript | JSON.stringify | JSON.parse | Nativo desde IE 8 (2009). Disponible en todos los navegadores y Node. |
| Python | json.dumps | json.loads | ensure_ascii=False renuncia al escape \uXXXX para no-ASCII. |
| PHP | json_encode | json_decode | Nativo desde PHP 5.2 (nov 2006). Bandera JSON_UNESCAPED_UNICODE desde 5.4. |
| Java | ObjectMapper.writeValueAsString | readTree | Jackson es el estándar de facto desde ~2009. |
| Go | json.Marshal | json.Unmarshal | Biblioteca estándar encoding/json. |
| Rust | serde_json::to_string | serde_json::from_str | El crate serde_json, omnipresente. |
De dónde viene JSON, y qué dejó fuera Crockford
JSON fue formalizado por primera vez por Douglas Crockford en 2001 en State Software, originalmente para serializar objetos JavaScript para intercambio de datos asíncrono. La primera mención pública fue en el sitio JSON.org en 2003. Crockford lo especificó formalmente como RFC 4627 en julio de 2006, en parte para combatir un intento de patente competidor más o menos en la misma época. El estándar se movió al estatus STD 90 con RFC 8259 en diciembre de 2017.
La mayor decisión de diseño de JSON fue convertirlo en un subconjunto de JavaScript, para que cualquier documento JSON pudiera ser eval'd en un intérprete JS y producir el valor correcto. Esto hizo que la adopción en el navegador fuera sin fricción pero bloqueó algunas particularidades de JS de forma permanente: sin tipo entero (todos los números son dobles IEEE 754), sin tipo de fecha, sin NaN o Infinito. Los enteros grandes por encima de 2⁵³−1 necesitan serialización como cadena ("id": "9007199254740993") para evitar pérdida silenciosa de precisión.
Crockford dejó deliberadamente fuera cosas que podrías echar de menos: comentarios («Quité los comentarios de JSON porque vi que la gente los usaba para contener directivas de parsing, una práctica que habría destruido la interoperabilidad», mayo 2012), comas finales, y lenguaje de esquema (añadido más tarde como JSON Schema, mantenido separadamente, borrador actual 2020-12). La variante comunitaria JSON5 restaura comentarios y comas finales pero no es RFC-conforme; se usa principalmente en archivos de configuración (.babelrc, .swcrc) que editan humanos.
Casos de uso comunes
- Incrustar datos en atributos HTML, pegar una cadena con
",<,>, obtener una forma segura para atributosdata-*o etiquetasscriptinline. - Componer cuerpos de petición API a mano, cuando se curlea un endpoint y el payload contiene comillas o saltos de línea.
- Construir payloads de líneas de log donde el mensaje debe sobrevivir al quotado shell más el parsing JSON en el otro lado.
- Migrar datos legacy de CSV / XML / TSV a JSON, pasada manual de escape de comillas.
- Depurar respuestas del servidor donde el valor contiene secuencias
\u, desescapar para ver lo que es realmente. - Escribir pruebas, pegar la salida JSON esperada y escaparla para incluirla en una aserción de prueba.
- Motores de plantillas (Jinja2, Nunjucks, Liquid, ERB) que incrustan JSON en JavaScript o HTML.
Errores comunes
- Usar escapes JavaScript que no son JSON válidos.
\x41para «A» y\012para salto de línea son válidos en literales de cadena JS pero inválidos en JSON. JSON solo permite los ocho escapes nombrados más\uXXXX. - Usar comillas simples para cadenas JSON.
'hello'funciona en JavaScript pero es JSON inválido. Las cadenas JSON DEBEN usar comillas dobles. - Claves de objeto sin comillas.
{name: "Bob"}funciona en JavaScript pero es JSON inválido. Las claves DEBEN ser literales de cadena entre comillas dobles. - Comas finales.
[1,2,3,]funciona en JS pero es JSON inválido. RFC 8259 las prohíbe explícitamente. - Comentarios inline.
// fooy/* foo */son inválidos en JSON estándar. Usa JSON5 si necesitas comentarios; espera que no todos los parseadores lo acepten. - Escapar manualmente un emoji como un solo
\uXXXX. Los emoji por encima de U+FFFF necesitan una pareja suplente UTF-16, dos\uXXXXconsecutivos.
Más preguntas frecuentes
¿Debo escapar siempre la barra /?
No, la barra / está permitida sin escapar en JSON; el escape \/ es opcional. La excepción es cuando JSON está incrustado dentro de una etiqueta HTML <script>: escapar / como \/ previene que la subcadena literal </script> cierre la etiqueta prematuramente. Algunos codificadores (JSON_HEX_TAG en PHP, reemplazos JS personalizados) lo hacen; la mayoría no.
¿Por qué JSON.stringify escapa mis caracteres no-ASCII?
No lo hace, por defecto. JSON.stringify("café") en JavaScript produce "café" con el é literal. Lo que puedes estar viendo es una biblioteca diferente: json.dumps de Python por defecto usa ensure_ascii=True y escapa todo fuera de ASCII como \uXXXX; json_encode de PHP se comporta similar a menos que pases JSON_UNESCAPED_UNICODE. Ambos comportamientos son JSON válido, pero el tamaño del archivo y la legibilidad difieren.
¿Puede JSON almacenar datos binarios?
No directamente. Las cadenas JSON son secuencias de caracteres Unicode, no bytes. El workaround estándar es codificar Base64 el binario primero, luego almacenar la cadena ASCII resultante como un valor JSON normal. Los datos codificados son ~33% más grandes que los bytes brutos. Para binarios muy grandes, usa un formato binario como BSON, MessagePack o CBOR, o almacena los bytes separadamente y referénciálos por URL.
¿Por qué algunas herramientas muestran \u00e9 en lugar de é?
Ambos son JSON válidos para el mismo carácter. "caf\u00e9" y "café" decodifican a cadenas idénticas. Algunos codificadores escapan no-ASCII para máxima seguridad de cross-encoding (la salida es ASCII puro así que la codificación del consumidor no importa), otros preservan el UTF-8 original para legibilidad. Elige basándote en lo que consume tu JSON.
¿Se sube mi texto a algún lado?
No. La herramienta usa las APIs nativas JSON.stringify y JSON.parse del navegador enteramente en el cliente. No hay llamada de red, ni analítica, ni logging. Seguro para escapar tokens API, datos internos, o cualquier cosa que no pegarías en una herramienta de escape del lado del servidor.