Base64 vs Base64 URL-safe (y cuándo un JWT necesita el segundo)
Base64 estándar usa +/= ; el URL-safe cambia a -/_ y suele omitir padding. Cómo QSTools codifica texto UTF-8 en el navegador.
Base64 convierte bytes a ASCII para que sobrevivan email, JSON y copy-paste. Es encoding, no cifrado: cualquiera puede decodificarlo. El texto UTF-8 debe convertirse a bytes primero; de lo contrario, los caracteres no-ASCII romperán un uso ingenuo de btoa.
Estándar vs URL-safe
| Variante | Alfabeto / padding | Uso típico |
|---|---|---|
| Estándar (RFC 4648 §4) | A–Z a–z 0–9 + / con padding = |
MIME, muchas APIs, blobs de config |
| URL-safe (RFC 4648 §5) | - _ en lugar de + /; padding a menudo omitido |
Query strings, filenames, segmentos JWT |
El header y el payload de un JWT utilizan Base64URL (URL-safe) para evitar depender de los caracteres + y / en las rutas. Si pegas un JWT en un decodificador que solo soporta el formato estándar, es posible que observes errores falsos.
Qué hace QSTools
La herramienta Base64 Encode / Decode se ejecuta íntegramente en el navegador, soporta UTF-8 e incluye un interruptor para el modo URL-safe. Codificar transforma texto a Base64; Decodificar realiza el proceso inverso. La función Swap resulta útil para probar el ciclo completo de un ejemplo.
Fallos comunes al decodificar
- Paste truncado o whitespace de más (en decode sacamos espacios/saltos)
- Mezclar input URL-safe con modo estándar (o al revés)
- Binario que no es UTF-8 válido cuando esperás texto legible
Para inspeccionar tokens de principio a fin, combínalo con el Decodificador JWT — que también se ejecuta del lado del cliente.