Calculadora de Tamaño de Token JWT
Mide un JWT con exactitud: Base64URL sin relleno y bytes UTF-8 reales. Luego compruébalo contra los límites de cookie, cabecera Authorization y URL.
Pega tus claims como un objeto JSON. Los espacios se ignoran: una librería JOSE serializa el objeto, así que el token lleva la forma minificada.
¿Cuánto puede medir realmente un JWT?
La especificación del JWT no fija ningún máximo: el límite siempre viene de lo que transporta el token. La cifra de la cookie cuenta el nombre, el valor y todos los atributos.
| Dónde aprieta el límite | Bytes | Fuente |
|---|---|---|
| Una cookie: nombre + valor + atributos | 4096 | RFC 6265 §6.1 |
| Un campo de cabecera (predeterminado de nginx) | 8192 | nginx large_client_header_buffers |
| Un campo de cabecera (predeterminado de Apache) | 8190 | Apache LimitRequestFieldSize |
| Todo el bloque de cabeceras (predeterminado de Node.js) | 16.384 | Node.js http.maxHeaderSize |
| Longitud de URI que se debería admitir | 8000 | RFC 9110 |
Tamaño de la firma por algoritmo
Las firmas HMAC son la salida del hash (RFC 7518 §3.2). RSA y RSA-PSS tienen el tamaño del módulo, así que siguen la longitud de clave que elijas (§3.3, §3.5). ECDSA concatena R y S con la longitud del orden de la curva (§3.4). Las firmas EdDSA son de 2b bits (RFC 8032 §5.1).
| alg | Algoritmo | Bytes de firma | Caracteres codificados |
|---|---|---|---|
| HS256 | HMAC SHA-256 | 32 | 43 |
| HS384 | HMAC SHA-384 | 48 | 64 |
| HS512 | HMAC SHA-512 | 64 | 86 |
| RS256 | RSASSA-PKCS1-v1_5 SHA-256 | 256 | 342 |
| RS384 | RSASSA-PKCS1-v1_5 SHA-384 | 256 | 342 |
| RS512 | RSASSA-PKCS1-v1_5 SHA-512 | 256 | 342 |
| PS256 | RSASSA-PSS SHA-256 | 256 | 342 |
| PS384 | RSASSA-PSS SHA-384 | 256 | 342 |
| PS512 | RSASSA-PSS SHA-512 | 256 | 342 |
| ES256 | ECDSA P-256 | 64 | 86 |
| ES384 | ECDSA P-384 | 96 | 128 |
| ES512 | ECDSA P-521 | 132 | 176 |
| EdDSA | EdDSA Ed25519 | 64 | 86 |
| EdDSA | EdDSA Ed448 | 114 | 152 |
| none | Sin protección, sin firma | 0 | 0 |
Calculadoras Relacionadas
También podrías encontrar útiles estas calculadoras
Calculadora de Riesgo de Alcance OAuth
Evalúa el riesgo de seguridad de configuraciones de alcance OAuth 2,0
Calculadora de caducidad de certificados SSL
Días restantes, fecha de renovación y vigencia máxima de un certificado TLS
Comparación de Fuerza de Clave
Qué claves AES, RSA, ECC y hash tienen la misma fuerza.
Generador de Hash SHA-256 y MD5
Genera y verifica hashes SHA-256, MD5, SHA-1, SHA-512 y SHA-3
Mide tu JWT antes de que un navegador lo descarte
Pega los claims de tu token, elige el algoritmo con el que lo firmas y obtén su longitud exacta en caracteres, junto con la comprobación de si cabe en una cookie, en una cabecera Authorization o en una URL. Los tres límites cuentan también el envoltorio, no solo el token.
¿Qué determina el tamaño de un JWT?
Un JSON Web Token son tres partes codificadas en Base64URL unidas por puntos: cabecera, carga útil y firma. Dos detalles deciden su longitud exacta y ambos son fáciles de equivocar. Primero, un JWS usa Base64URL omitiendo todo el relleno '=' final (RFC 7515 §2), así que una parte de n bytes se codifica en ⌈4n/3⌉ caracteres: una firma HS256 mide 43 caracteres, no 44. Segundo, esos n son bytes UTF-8, no caracteres: un nombre en español, árabe o chino cuesta más de lo que aparenta, y un emoji cuesta cuatro bytes. La longitud de la firma viene del algoritmo (32 bytes en HS256, el tamaño del módulo en RSA, 64 bytes en ECDSA P-256) y la carga útil son los claims que decidas incluir, que es la única parte que controlas.
Fórmula
Token = ⌈4×|cabecera|/3⌉ + ⌈4×|carga útil|/3⌉ + ⌈4×|firma|/3⌉ + 2Cómo usar la calculadora
Elige el algoritmo de firma de tu emisor y, en RSA o RSA-PSS, la longitud de clave: la firma tiene el tamaño del módulo.
Pega tus claims como un objeto JSON. Los espacios se ignoran, porque una librería JOSE serializa el objeto antes de codificarlo.
Añade el 'kid' que envíe tu emisor, si lo hay. Todo proveedor basado en JWKS incluye uno y forma parte de la cabecera que pagas.
Lee el tamaño del token y después la comprobación por portador: cookie, cabecera Authorization y URL se miden cada una con su propio envoltorio.
Si algo se pasa, mira los avisos: los arreglos y los nombres de claim largos casi siempre son lo más barato de recortar.
Cuándo usarla
Decidir si el token cabe en una cookie
Calcula el token junto con el nombre de la cookie y los atributos que realmente pones, porque esa suma es lo que cubre la garantía de 4096 bytes.
Medir un token antes de añadir un claim
Pega la carga útil que tienes y la que quieres, y compara. Los arreglos de roles y permisos dominan casi cualquier token real.
Comparar algoritmos para un servicio nuevo
La misma carga útil aparece firmada de todas las formas documentadas, así que el coste de RS256 frente a ES256 o EdDSA es un número y no una intuición.
Diagnosticar un 400 o un 431 que no reproduces en local
Un servidor de desarrollo con un bloque de cabeceras de 16 KB acepta sin problema un token que nginx rechaza a los 8 KB. La tabla muestra los tres valores predeterminados juntos.
Por qué importa el tamaño de un token
El límite es del portador, no del token
El RFC 6265 §6.1 solo garantiza 4096 bytes por cookie, medidos sobre el nombre, el valor y todos los atributos. Un token de 4050 caracteres más 'session=' y '; Path=/; Secure; HttpOnly; SameSite=Lax' ya se ha pasado.
Los tokens viajan en cada petición
Un token bearer se reenvía en cada llamada. Un kilobyte más de claims es un kilobyte más en cada petición de cada cliente, y eso aparece como latencia mucho antes que como error.
Los límites de cabecera fallan antes que tu código
nginx rechaza con 400 un campo de cabecera mayor que un búfer de 8k, y el valor predeterminado de LimitRequestFieldSize en Apache es 8190. Ninguno de esos fallos llega a tu aplicación, así que cuesta diagnosticarlos desde dentro.
El algoritmo mueve el suelo, no el techo
Cambiar RS256 por ES256 lleva la firma de 342 caracteres codificados a 86. Es un ahorro fijo en cada token y no cuesta nada en seguridad.
Los claims con tildes cuestan más de lo que parecen
Un nombre visible en español o en chino se mide en bytes UTF-8 antes de codificarse. Contar caracteres en su lugar subestima el token, que es justo la dirección en la que no quieres equivocarte al comprobar un límite.
Preguntas frecuentes
Las especificaciones del JWT no fijan ningún máximo: cada límite viene de lo que transporta el token. En la práctica: 4096 bytes para una cookie incluyendo su nombre y sus atributos (RFC 6265 §6.1), 8192 bytes por campo de cabecera en nginx y 8190 en Apache, 16384 bytes para todo el bloque de cabeceras en Node.js, y 8000 octetos de URI que el RFC 9110 dice que los emisores deberían admitir. El más ajustado casi siempre es la cookie, porque los atributos también cuentan.
Porque un JWS elimina el relleno de Base64. El RFC 7515 §2 define la codificación Base64URL como base64url «omitiendo todos los caracteres '=' finales», así que n bytes pasan a ⌈4n/3⌉ caracteres y no a ⌈n/3⌉×4. Una salida HMAC-SHA-256 de 32 bytes son 43 caracteres. La misma regla lleva una firma RS256 de 2048 bits a 342 caracteres y una ES256 a 86.
Base64 representa cada 3 bytes con 4 caracteres, así que la forma codificada mide 4/3 del original: alrededor de un 33 % más. Esa proporción es constante y se aplica a cada una de las tres partes. No es lo mismo que la proporción del token que no es carga útil, que va desde un pequeño porcentaje en un token grande hasta casi todo en uno pequeño.
EdDSA con Ed25519 y ECDSA P-256 producen firmas de 64 bytes, que se codifican en 86 caracteres, y HS256 produce 32 bytes y 43 caracteres. Las firmas RSA y RSA-PSS tienen el tamaño de la clave: 256 bytes con 2048 bits (342 caracteres), 384 con 3072 (512 caracteres) y 512 con 4096 (683 caracteres). Pasar de RS256 a ES256 ahorra 256 caracteres en cada petición.
Sí, y más de lo que cabría esperar. La carga útil se codifica a partir de sus bytes UTF-8: un carácter latino con tilde ocupa 2 bytes, uno chino o árabe 3, y un emoji 4. Un nombre chino de veinte caracteres son 60 bytes, no 20, y se codifica en 80 caracteres en lugar de 27.
Un poco, y de forma exacta. La cabecera pasa de 15 bytes a 27 al añadir el tipo, lo que se codifica en 20 y 36 caracteres: una diferencia de 16 caracteres, una sola vez, para toda la vida del token. Un 'kid' cuesta mucho más: un identificador de clave de 27 caracteres añade 35 bytes de cabecera y 48 caracteres de token.
Solo lo que un servidor de recursos comprueba en la petición. Los claims registrados (iss, sub, aud, exp, nbf, iat, jti) tienen tres letras por algo. Los arreglos grandes de roles o permisos son la causa habitual de un token demasiado grande; enviar un identificador y resolver el resto en el servidor es la solución estándar. Nunca pongas nada secreto en la carga útil: está codificada, no cifrada.
En localStorage no: cualquier cosa inyectada en tu página puede leerlo, y eso convierte un problema de tamaño en uno de filtración. La respuesta habitual es dejar de enviar los claims. Emite un identificador de sesión opaco y corto en la cookie y guarda los claims en el almacén de sesión, o divide el token para que solo viaje en la cookie lo que el navegador necesita.