O secret ou o token gerado são enviados para algum servidor?

Não. A assinatura é feita no seu navegador com a Web Crypto API. O secret, o header, o payload e o token não são enviados para servidor nenhum, não entram nos eventos de analytics e não ficam salvos quando você fecha a página.

Posso usar o secret de produção aqui?

Não use. Mesmo com tudo rodando no navegador, quem tem o secret de produção consegue emitir token de qualquer usuário. Para testes, configure um secret próprio no ambiente de homologação ou use o gerado aqui.

Gerei o token e a API recusou. O que conferir?

Confira se o secret é o mesmo do backend, inclusive se ele está em Base64 lá; se o algoritmo configurado na API é o mesmo do token; se o exp está no futuro e o nbf no passado; e se iss e aud batem com o que a API espera.

Por que não dá para gerar token RS256 ou ES256?

Porque exigiria colar uma chave privada no navegador. Esse tipo de chave deve ficar só no servidor que emite os tokens. Para APIs que validam RS256, peça o token ao provedor de homologação e use o Decodificador de JWT para conferir as claims.

Como defino quando o token expira?

Use os atalhos exp +15 min, +1 h, +1 dia ou +7 dias, que calculam o horário a partir de agora, ou edite o exp no JSON em segundos Unix. O atalho exp vencido cria um token já expirado.

Para que serve o jti?

É um identificador único do token. APIs usam o jti para bloquear reuso ou para revogar um token específico. O atalho gera um UUID v4 novo a cada clique.

Quando marcar a opção de secret em Base64?

Quando o backend guarda o secret codificado em Base64 e decodifica antes de usar, como fazem algumas configurações de Spring e de bibliotecas Java. Se o backend usa o texto do secret direto, deixe a opção desmarcada.

Gerador de JWT

Monte o header e as claims, informe o secret e copie um token JWT assinado com HS256, HS384 ou HS512. Serve para testar login, perfis de acesso e expiração sem depender do provedor de identidade.

Gerador para testes. Use um secret de homologação ou o aleatório gerado aqui, nunca o secret de produção. A assinatura é feita no seu navegador e nada é enviado para servidor.

Algoritmo

HMAC com SHA-256, SHA-384 ou SHA-512. Quem valida o token precisa do mesmo secret.

Perfil de teste

Header

O alg do header acompanha o algoritmo escolhido.

Payload (claims)

Adicionar claim

Secret

O secret está em Base64

Token gerado

O token aparece aqui assim que o header, o payload e o secret estiverem válidos.

Recebeu um token e quer ver o que tem dentro dele?

Abrir o Decodificador de JWT

Como usar o Gerador de JWT?

Monte as claims

Escolha um perfil de teste ou edite o JSON do payload. Os atalhos adicionam exp relativo, iat, jti e outras claims comuns.

Informe o secret

Use o mesmo secret configurado no backend de teste ou gere um aleatório com o tamanho certo para o algoritmo.

Veja o token

O token é assinado a cada alteração, sem botão. O resumo mostra quando ele expira.

Copie e teste

Copie o token ou o header Authorization pronto e use no Postman, no curl ou no teste automatizado.

Para que gerar um JWT de teste

Nem sempre dá para logar no provedor de identidade a cada cenário de teste. Com um token gerado aqui, você testa a API com o perfil que quiser, inclusive casos difíceis de reproduzir, como um token já expirado ou sem uma role. Funciona quando o backend de teste valida o token com um secret HMAC que você conhece.

Cenários que valem um token de teste

Admin e usuário comum com o mesmo sub, para conferir se a rota bloqueia quem não tem a role
Token expirado, para garantir que a API responde 401 e que o front pede um novo token
Token com nbf no futuro, para testar a recusa de um token que ainda não vale
Token sem a claim roles ou com scope incompleto, para testar a resposta 403
Token com aud de outra API, para confirmar que a API não aceita token alheio
Assinatura com outro secret, para confirmar que a API recusa token adulterado

HS256, RS256 e ES256: qual é a diferença

HS256 usa um secret compartilhado: o mesmo valor assina e verifica, então quem valida também consegue emitir tokens. RS256 usa um par de chaves RSA: o provedor assina com a chave privada e as APIs verificam com a pública, que pode ser divulgada. ES256 faz o mesmo com curvas elípticas, com chaves e assinaturas bem menores. Provedores como Keycloak, Auth0 e Cognito assinam com RS256 por padrão.

Este gerador assina só com HMAC de propósito. Assinar RS256 ou ES256 exigiria colar uma chave privada no navegador, e chave privada não deve sair do servidor que emite os tokens. Para testar uma API que valida RS256, gere o token no próprio ambiente de homologação do provedor.

Como a assinatura HMAC é calculada

O gerador codifica o header e o payload em base64url, junta os dois com um ponto e calcula o HMAC desse texto com o secret. O resultado, também em base64url, vira a terceira parte do token. Por isso qualquer mudança no payload, até um espaço, gera uma assinatura diferente, e o backend recusa um token alterado sem conhecer o secret.

Tamanho do secret

A RFC 7518 pede que o secret tenha pelo menos o tamanho da saída do hash: 32 bytes para HS256, 48 para HS384 e 64 para HS512. Um secret como senha123 assina normalmente, mas pode ser descoberto por força bruta a partir de um token capturado. O botão Gerar aleatório cria um secret com o tamanho mínimo para o algoritmo escolhido.

Como enviar o token na requisição

A forma mais comum é o header Authorization com o prefixo Bearer. O botão Copiar Authorization já copia a linha pronta. No curl, fica assim:

curl -H "Authorization: Bearer SEU_TOKEN" https://api.homolog.exemplo.com/pedidos

Perguntas Frequentes sobre o Gerador de JWT

Dúvidas comuns de quem gera tokens JWT para testes.