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 codificación, no cifrado: cualquiera puede decodificarlo. El texto UTF-8 debe convertirse a bytes primero; si no, los caracteres no ASCII rompen 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, nombres de archivo, segmentos JWT |
El header y el payload de un JWT usan Base64URL (URL-safe) para no depender de + y / en rutas. Si pegas un JWT en un decoder solo “estándar”, puedes ver fallos engañosos.
Qué hace QSTools
La herramienta Base64 Encode / Decode corre entera en el navegador, soporta UTF-8 y tiene interruptor para modo URL-safe. Codificar pasa texto a Base64; Decodificar hace lo inverso. Swap sirve para probar ida y vuelta con un ejemplo.
Fallos comunes al decodificar
- Pegado truncado o espacios/saltos de más (en decode los quitamos)
- Mezclar entrada URL-safe con modo estándar (o al revés)
- Binario que no es UTF-8 válido cuando esperas texto legible
Para inspeccionar tokens de punta a punta, combínalo con el Decodificador JWT — también del lado del cliente.