Decodificar Base64

Por orden de frecuencia: un JWT, una cabecera de Basic Auth, el valor de un secreto de Kubernetes, un payload de webhook. Tres de esas cuatro son credenciales, y la cuarta suele llevar datos de personas.

Por eso esta página no tiene servidor detrás. No es una postura: es la consecuencia directa de para qué se usa. Una herramienta que decodifique esto en remoto ha visto la credencial y la tiene en su registro de peticiones, y ningún aviso legal cambia ese hecho.

Un JWT es cabecera, payload y firma, separados por puntos y cada uno en Base64 seguro para URL. Las dos primeras partes son JSON y se leen sin más; la tercera es la firma y no es texto, así que decodificarla no da nada aprovechable.

La consecuencia incómoda es que el contenido de un token no es secreto: cualquiera que lo tenga puede leer a quién pertenece, cuándo caduca y qué permisos declara. La firma impide modificarlo, no leerlo. Meter datos personales en el payload de un JWT es, por tanto, publicarlos ante cualquiera que vea el token.

Una cadena en Base64 puede contener un PNG, un PDF o un ZIP igual de bien que una frase. Al leer esos bytes como texto salen símbolos de sustitución, y muchas herramientas te devuelven eso tal cual, con lo que parece que el Base64 estaba roto cuando estaba perfecto.

Aquí se distingue: si la cadena es Base64 válido pero los bytes no forman texto, se te dice eso y cuántos bytes son. Es la respuesta útil, porque cierra la búsqueda de un error de codificación que no existe y traslada la pregunta a qué clase de datos son en realidad.

Los JWT quitan los signos igual del final a propósito, porque la especificación de Base64 seguro para URL lo permite. Muchas bibliotecas, en cambio, se niegan a decodificar sin relleno y devuelven un error que no explica nada.

Este decodificador lo repone solo cuando hace falta, así que un token copiado de una cabecera se lee tal cual. Si tu código falla con un valor que aquí funciona, esa suele ser la razón exacta, y la solución es rellenar hasta el siguiente múltiplo de cuatro antes de pasárselo a la biblioteca.

El alfabeto estándar usa `+` y `/`; el seguro para URL usa `-` y `_`. Aquí se admiten ambos sin preguntar, porque saber cuál te ha tocado no debería ser un requisito previo para leer una cadena que alguien te ha pegado.

Sí conviene saberlo en el otro sentido. Si estás generando un valor que va a viajar en una dirección y usas el alfabeto estándar, la barra romperá la ruta y el más se leerá como espacio: el valor llega, pero cambiado, y el fallo aparece muy lejos del sitio donde se produjo.

El correo parte el Base64 en líneas de 76 caracteres y los certificados PEM en 64, porque así lo exigen sus estándares. Un valor copiado de un fichero `.pem` o del cuerpo de un correo llega, por tanto, con saltos de línea dentro.

Se ignoran, junto con los espacios sueltos que aparecen al copiar de un terminal. No hay que limpiar nada antes: si algo de lo que has pegado no forma parte del alfabeto, se te dice cuál es el problema en lugar de decodificar a medias y devolver un resultado que parece bueno.

Que una cadena se decodifique no significa que su contenido sea correcto. Un JWT caducado se lee igual de bien que uno vigente, y una firma falsa se decodifica exactamente igual que una buena, porque comprobar la firma requiere la clave y esta página no la tiene ni la quiere.

Sirve para leer, no para confiar. Si lo que necesitas es saber si un token es válido, eso lo tiene que decir el sistema que lo emitió; lo que esta página responde es qué dice, que es una pregunta distinta y normalmente la primera.

Si en el resultado aparecen rombos con un interrogante, los bytes no formaban UTF-8 válido. Puede ser que sean datos binarios — un archivo, no texto — o que el texto se codificara originalmente en Latin-1 y ahora se esté leyendo como UTF-8.

Distinguir los dos casos es sencillo por el patrón: un archivo da basura desde el primer byte, mientras que un texto en Latin-1 se lee bien salvo justo en las tildes y las eñes. Ese segundo caso es el clásico de los datos españoles mal migrados, y aparece en una base de datos con la colación equivocada mucho antes que en un Base64.

Un `Secret` de Kubernetes guarda sus valores en Base64, y eso confunde a mucha gente: no está cifrado en reposo salvo que se configure aparte, y cualquiera con permiso para leer el recurso lee la credencial con un solo paso.

Por eso conviene tener claro qué protege qué. El Base64 está ahí para que valores binarios quepan en YAML, no para ocultarlos. La protección real son los permisos del clúster y, si hace falta, el cifrado en reposo — y un valor de un `Secret` pegado en una herramienta online es una credencial que ha salido del clúster.

De todas las páginas de este sitio, esta es la que más credenciales y datos personales recibe: payloads de webhook con nombres y direcciones, tokens que identifican a una persona, volcados de configuración. Como la decodificación ocurre en la página, nada de eso se nos comunica.

Es lo que hace utilizable la herramienta en un entorno con una política interna seria. Un servicio que decodificara en remoto habría recibido el dato personal y lo tendría en sus registros, y ese es exactamente el supuesto que esas políticas existen para evitar. El panel de red lo demuestra en un minuto.

Codificar tiene su propia página porque es otro momento. Quien codifica está montando algo y tiene que decidir el alfabeto; quien decodifica está leyendo algo que le ha llegado y necesita saber qué hacer cuando el resultado no es texto.

El motor es el mismo y las explicaciones no. Una página conjunta con un selector obligaría a cada visitante a atravesar la mitad que no le sirve, y las dos secciones que de verdad resuelven su problema quedarían diluidas entre las que no.