Cómo corregir Base64 inválido: padding incorrecto y longitud

Respuesta breve

Un error de padding en Base64 no se arregla añadiendo = al azar. Primero identifica si la entrada usa Base64 o Base64URL, elimina solo espacios de transporte y comprueba la longitud. Una longitud con resto 1 al dividir entre 4 es imposible; los restos 2 o 3 solo admiten padding reconstruible en perfiles que permiten omitirlo.

Qué significa «incorrect padding»

Base64 representa grupos de tres bytes mediante cuatro caracteres. Si el último grupo contiene uno o dos bytes, la forma estándar termina en == o =. Ese signo no es contenido: indica cuántas posiciones del último bloque no transportan datos.

Por eso SG9sYQ== decodifica Hola, mientras SG9sYQ es la misma secuencia sin padding. La segunda forma puede ser válida si el protocolo declara padding opcional, pero no conviene asumirlo. El conversor Base64 y Base64URL permite elegir la variante y valida la forma final antes de producir texto.

Diagnóstico por longitud

Ignorando saltos y espacios permitidos por la interfaz, calcula longitud % 4:

• Resto 0: puede estar completa, aunque aún hay que revisar alfabeto y bits.
• Resto 2: faltarían dos signos = en un perfil sin padding.
• Resto 3: faltaría un signo =.
• Resto 1: la secuencia no puede representar un bloque Base64 completo; falta información o hay un carácter de más.

No recortes caracteres para convertir un resto 1 en otro valor. Eso cambia los bytes y puede esconder una copia truncada.

Revisa el alfabeto antes de tocar el padding

Base64 estándar utiliza + y /; Base64URL utiliza - y _. Un JWT suele omitir padding y usar el segundo alfabeto. Sustituir caracteres sin saber qué formato exige el origen puede aceptar una entrada bajo reglas equivocadas.

También hay entradas con = en mitad del texto, más de dos signos finales o datos después del padding. Ninguno de esos casos se soluciona completando la longitud: hay que recuperar el valor original o corregir el productor.

Los bits finales también importan

Dos cadenas pueden decodificar aparentemente los mismos bytes aunque una use bits no canónicos en el último carácter. La RFC 4648 exige poner a cero esos bits de relleno para obtener una representación canónica. Una validación estricta evita múltiples cadenas equivalentes, algo importante en firmas, cachés y comparaciones.

Procedimiento seguro

1. Conserva una copia exacta de la entrada recibida.
2. Confirma si el contrato dice Base64 o Base64URL y si permite omitir =.
3. Retira solo el espacio añadido por transporte, no caracteres internos.
4. Valida alfabeto, posición del padding, longitud y bits canónicos.
5. Decodifica los bytes y, si esperas texto, valida UTF-8 por separado.

Si el origen es una API, corrige preferentemente el emisor. Normalizar en el consumidor solo es seguro cuando el protocolo documenta de forma explícita la variante sin padding.

Ejemplos rápidos

TQ== es la forma estándar de M; TQ puede aceptarse como Base64URL o en un perfil que omita padding. T=== tiene padding excesivo, T=Q= lo coloca en una posición inválida y A tiene longitud imposible. Un mensaje genérico de «padding incorrecto» puede corresponder a cualquiera de esos problemas, así que el detalle del diagnóstico importa más que añadir signos hasta que una biblioteca deje de protestar.