Codificador y decodificador Base64 / URL / JWT
Codifica y decodifica Base64 o URL e inspecciona la cabecera y la carga útil de un JWT en el navegador.
Cómo se usa
- Pega o escribe tu entrada en el cuadro «Texto o JWT»: texto normal para codificar, una cadena Base64 o con codificación porcentual para decodificar, o un JWT para inspeccionar.
- Haz clic en «Codificar Base64» o «Decodificar Base64» para convertir entre texto y Base64, o en «Codificar URL» o «Decodificar URL» para añadir o quitar la codificación porcentual. El resultado, o un mensaje de error, aparece en el cuadro «Salida».
- Para inspeccionar un token, pégalo con o sin el prefijo Bearer y haz clic en «Decodificar JWT». La cabecera y la carga útil aparecen como JSON con sangría, y los claims iat, nbf y exp de la carga útil se muestran en «Claims de tiempo del JWT», con los valores numéricos convertidos a UTC y a tu hora local.
- Haz clic en «Copiar resultado» para copiar la salida. Para deshacer una codificación, pega el texto codificado en el cuadro «Texto o JWT» y haz clic en el botón de decodificación correspondiente. Decodificar y volver a codificar puede no devolver exactamente el original: el Base64 seguro para URL o sin relleno vuelve con el alfabeto estándar y con relleno = donde hace falta, y «Codificar URL» convierte en %2B un + que haya dejado «Decodificar URL».
Preguntas frecuentes
¿Se envía a algún sitio el texto o el token que pego?
No. La codificación y la decodificación se hacen en tu navegador con JavaScript, y lo que introduces no se envía a LeedyBox. Un JWT se usa a menudo como credencial de inicio de sesión y puede servirle a cualquiera que lo tenga hasta que caduque o se revoque, así que trata un token vigente como una contraseña y no lo compartas en capturas de pantalla ni en chats.
¿Por qué «Decodificar Base64» dice que los datos no son texto UTF-8 válido?
«Decodificar Base64» muestra los bytes decodificados como texto UTF-8 y se detiene con este error cuando no son UTF-8 válido, por ejemplo con imágenes PNG o JPEG, con la mayoría de los PDF y con datos comprimidos, y a menudo con texto guardado en otra codificación como Latin-1 o Shift_JIS. La herramienta no guarda los bytes decodificados como archivo, así que úsala para Base64 que contenga texto. Una URI de datos como data:image/png;base64,... se rechaza como Base64 no válido, porque los dos puntos, el punto y coma y la coma no son caracteres Base64.
¿Admite Base64 seguro para URL y valores sin relleno?
Sí, al decodificar: «Decodificar Base64» acepta el alfabeto estándar (+ y /) y el alfabeto seguro para URL (- y _), con o sin relleno =, e ignora los espacios y los saltos de línea. «Codificar Base64» genera el alfabeto estándar con relleno; para la forma segura para URL que usan los JWT, sustituye + por -, / por _ y elimina los signos = finales. El texto se codifica en UTF-8 tal como lo escribes, así que un espacio o un salto de línea al final cambia el resultado, y los saltos de línea del cuadro se codifican como LF.
¿Debo pegar una URL completa para usar «Codificar URL»?
Normalmente no. «Codificar URL» funciona como encodeURIComponent de JavaScript: aplica codificación porcentual a todos los caracteres excepto A–Z, a–z, 0–9 y - _ . ! ~ * ' ( ), de modo que también se codifican los caracteres / ? & = : y # que estructuran una URL. Úsalo para una sola parte, como el valor de un parámetro de consulta. Los espacios pasan a ser %20 y los caracteres no ASCII se codifican como sus bytes UTF-8, así que é pasa a ser %C3%A9.
¿Por qué los signos más no se convierten en espacios y cuándo da error «Decodificar URL»?
«Decodificar URL» funciona como decodeURIComponent de JavaScript: decodifica las secuencias de escape %XX y deja + sin cambios, porque en la sintaxis general de las URL (RFC 3986) + no representa un espacio. Los datos de formularios HTML (application/x-www-form-urlencoded), que usan muchas cadenas de consulta, codifican los espacios como +, así que sustituye cada + por un espacio antes de decodificar esos datos; en ese formato, un signo más real se escribe como %2B y se sigue decodificando correctamente. El error aparece cuando un % no va seguido de dos dígitos hexadecimales, como en 50% off, o cuando los bytes escapados no son UTF-8 válido, como en %E2%82.
¿Qué tokens puede leer «Decodificar JWT»?
Los tokens con la forma compacta de tres partes header.payload.signature que usan los JWT firmados (JWS), incluidos los tokens sin firmar con la parte de la firma vacía. La firma no se comprueba, así que un token decodificado no demuestra que sea auténtico. Los tokens cifrados (JWE) tienen cinco partes y su carga útil no se puede leer sin la clave, así que dan un error de formato. Una cabecera o una carga útil que no se decodifica de Base64 a JSON, o una carga útil que es un valor simple, como una cadena o un número, en lugar de un objeto JSON, da un mensaje «Error al analizar el JWT». Los enteros mayores que 9.007.199.254.740.991 en la cabecera o en la carga útil pueden redondearse cuando el navegador analiza el JSON, así que los ID numéricos largos pueden mostrarse con las últimas cifras distintas.
¿Cómo se muestran las horas exp, nbf e iat y cuándo se marca un token como caducado?
Los valores se leen como tiempo Unix en segundos, tal como los define el estándar JWT (RFC 7519), y se muestran en UTC y en tu hora local. «CADUCADO» y «Aún no es válido» comparan exp y nbf con el reloj de tu dispositivo en el momento en que haces clic en «Decodificar JWT», sin ningún margen para diferencias de reloj, así que si el reloj está mal, el estado también lo estará. Los servidores pueden admitir un pequeño margen, a menudo de unos pocos minutos como mucho, así que cerca de la hora de exp o nbf un servidor puede decidir algo distinto de lo que indica el estado que se muestra aquí. Una hora escrita como cadena, como "1700000000", se indica como marca de tiempo Unix numérica no válida.