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 hay que pasarlo a bytes primero; si no, caracteres no-ASCII rompen un btoa ingenuo.
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 |
Header y payload de un JWT son Base64URL (URL-safe) para no depender de + / / en paths. Si pegás un JWT en un decoder “solo estándar”, podés ver fallos falsos.
Qué hace QSTools
La tool Base64 Encode / Decode corre entera en el navegador, soporta UTF-8 y tiene toggle URL-safe. Codificar = texto → Base64; Decodificar = al revés. Swap sirve para round-trip 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 mirar tokens de punta a punta, combiná con el Decodificador JWT — también client-side.