Decodifique o payload JWT sem verificar a assinatura

Ele devolve as duas partes como objetos estruturados, facilitando a inspeção ou o encaminhamento de claims, identificadores, timestamps, emissores, públicos e metadados do algoritmo. A assinatura não é verificada de propósito; portanto, os valores decodificados mostram o que o token declara, não quem o criou. Use o resultado em depuração, desenvolvimento, documentação e inspeções cuidadosas, nunca como prova de autenticidade ou autorização do token.

Entenda o que a decodificação comprova e o que não comprova

Um JWT costuma conter cabeçalho, payload e assinatura, unidos por pontos. Os dois primeiros segmentos são JSON codificado em base64url. Isso significa que o conteúdo foi preparado para transporte compacto, mas não está criptografado nem oculto. Esta capacidade divide o token informado, decodifica esses dois segmentos como UTF-8, analisa o JSON e devolve os objetos resultantes de cabeçalho e payload. O terceiro segmento não é usado para autenticar nada. Essa distinção é essencial, pois qualquer pessoa pode criar uma sequência com formato de token e claims arbitrárias. Encontrar um sujeito, uma função, um emissor, um público ou uma expiração no payload decodificado não prova que um sistema confiável emitiu o token. Use a decodificação para visualizar a estrutura, diagnosticar nomes ou valores de claims ou obter uma representação legível durante o desenvolvimento. Quando uma decisão de segurança depender do token, use uma biblioteca de verificação JWT apropriada com chave explicitamente confiável e restrições de algoritmo, emissor e público.

Envie um JWT compacto e interprete a resposta

Cole ou envie o JWT compacto completo no campo token. Um token estruturalmente válido tem exatamente três segmentos separados por dois pontos, embora este decodificador leia apenas os dois primeiros. A resposta contém um objeto header e um objeto payload. Campos comuns do cabeçalho incluem typ, que geralmente identifica o tipo de mídia JWT, e alg, que informa o suposto algoritmo de assinatura. Campos comuns do payload incluem sub para sujeito, iss para emissor, aud para público, exp para expiração e claims específicas do aplicativo. Este decodificador não exige nenhuma claim; ele preserva os valores JSON presentes. Claims NumericDate como exp, nbf e iat continuam sendo números, sem conversão em datas, evitando suposições sobre como você pretende exibi-las ou compará-las. Se o token tiver quantidade incorreta de segmentos, base64url malformado, UTF-8 ou JSON inválido, ou uma seção decodificada que não seja objeto, a solicitação retornará um erro de entrada inválida em vez de um resultado parcial.

Use claims decodificadas com segurança no desenvolvimento

A decodificação é especialmente útil na fronteira entre sistemas. Uma pessoa que desenvolve uma API pode comparar as claims produzidas por um provedor de identidade com os nomes esperados pelo aplicativo. A equipe de suporte pode inspecionar um token de teste com dados ocultados para descobrir se falta um público ou escopo. Uma suíte de testes pode decodificar tokens criados por uma fixture local e confirmar a inclusão das claims personalizadas antes de testar a verificação criptográfica separadamente. Mantenha o limite de segurança explícito em todo fluxo: dados decodificados são entradas não confiáveis. Não conceda acesso, selecione um tenant, aceite uma identidade nem exponha dados privados apenas porque uma claim decodificada solicita isso. Evite colar tokens bearer reais em logs, tickets, chats ou documentos compartilhados, pois um JWT pode ser uma credencial ativa mesmo quando seu payload parece inofensivo. Prefira exemplos sintéticos, expirados ou gerados localmente para diagnóstico. Se uma automação precisar processar tokens reais, envie-os somente por um canal devidamente protegido e faça a verificação usando configurações confiáveis após a decodificação.