O token ainda não expirou, mas a API recusa a requisição
A data de expiração é apenas uma das verificações. Confira aud, que informa o destinatário esperado e pode ser uma string ou um array. iss identifica o emissor e sub, o sujeito do token. Um token emitido para outra API pode ser recusado mesmo antes de expirar.
As claims são declarações presentes no próprio token. A leitura não confirma que o emissor é confiável. A aplicação ou o protocolo define quais campos são obrigatórios e quais valores devem ser aceitos.
O que há nas três partes do JWT
Um JWT assinado normalmente usa header.payload.signature. Header e payload contêm objetos JSON em UTF-8 codificados em Base64url. A última parte representa bytes de assinatura ou MAC, e não um terceiro objeto JSON.
Cole o token sozinho, com Bearer ou com Authorization: Bearer. Não inclua a requisição HTTP inteira. Os dois blocos JSON podem ser copiados separadamente. Números inteiros grandes e a forma original dos números são preservados no conteúdo exibido e copiado.
Expiração em segundos, não em milissegundos
exp indica a expiração, nbf o início permitido de uso e iat a emissão. NumericDate usa segundos desde a época Unix. O valor 1704067200 corresponde a 1º de janeiro de 2024, às 00:00 UTC. Um timestamp JavaScript em milissegundos não deve ser usado diretamente como esse valor.
A comparação usa o relógio do dispositivo, sem tolerância a diferenças de horário. Uma expiração futura não comprova que a assinatura está correta. Uma emissão no futuro aparece como informação para investigação; a regra de rejeição pertence à aplicação.
Ler o conteúdo não valida a assinatura
Base64url é uma codificação, não uma criptografia. Para aceitar o token, o serviço precisa definir chaves confiáveis e algoritmos permitidos, verificar a proteção criptográfica e conferir emissor, destinatário, tempo e demais claims exigidas. O alg declarado pelo token não deve decidir sozinho a configuração de confiança.
O decodificador não acessa URLs de chaves nem usa chaves incorporadas. Não descriptografa JWE de cinco partes, não processa JWT aninhados e não aceita b64: false. O limite é de 50.000 caracteres e 64 níveis JSON. Chaves duplicadas são recusadas para evitar interpretações conflitantes.
Explore os exemplos
Token expirado
Claims fictícias e assinatura ilustrativa; não é uma credencial utilizável.
Voltar ao decodificador JWT ↑Claims Unicode
Texto em vários idiomas e múltiplos destinatários; assinatura ilustrativa.
Voltar ao decodificador JWT ↑Perguntas frequentes
Posso decodificar sem secret?
Sim, para um JWT de três partes com header e payload JSON. Ler Base64url não exige chave. O secret ou a chave pública faz parte da verificação criptográfica, que não é realizada por esta ferramenta.
O que significa alg: none?
É um JWT sem assinatura criptográfica. A terceira parte fica vazia, mas o ponto final continua fazendo parte do token. O fato de ser legível não o torna confiável para autenticação.
O token é enviado para um servidor?
A ferramenta processa a entrada no navegador, sem enviá-la a uma API de decodificação, salvá-la ou colocá-la na URL. Um Bearer real pode conceder acesso a uma conta ou serviço; use os exemplos fictícios para conhecer o funcionamento.
Qual é a diferença entre os exemplos?
O expirado tem exp em 1º de janeiro de 2024 às 01:00 UTC e uma assinatura ilustrativa. O exemplo Unicode contém vários idiomas e um array de destinatários, também com assinatura ilustrativa. O exemplo sem assinatura usa alg: none. Nenhum funciona como credencial.
Por que o JWT não abre?
Confira se as três partes estão completas e se não há espaços, aspas ou preenchimento. Header e payload devem ser objetos JSON UTF-8. Chaves repetidas e assinatura vazia incompatível com alg causam erro. Cinco partes geralmente indicam um JWE criptografado.