Codificador e decodificador Base64 / URL / JWT

Não. A codificação e a decodificação são feitas no seu navegador com JavaScript, e o que você digita não é enviado à LeedyBox. Um JWT costuma ser usado como credencial de login e pode funcionar para qualquer pessoa que o tenha até expirar ou ser revogado, então trate um token ainda ativo como uma senha e não o compartilhe em capturas de tela ou chats.

"Decodificar Base64" mostra os bytes decodificados como texto UTF-8 e para com esse erro quando eles não são UTF-8 válido, por exemplo em imagens PNG ou JPEG, na maioria dos PDFs e em dados compactados e, muitas vezes, em texto salvo em outra codificação, como Latin-1 ou Shift_JIS. A ferramenta não salva os bytes decodificados como arquivo, então use-a para Base64 que contém texto. Um data URI como data:image/png;base64,... é rejeitado como Base64 inválido, porque os dois-pontos, o ponto e vírgula e a vírgula não são caracteres Base64.

Sim, na decodificação: "Decodificar Base64" aceita o alfabeto padrão (+ e /) e o alfabeto seguro para URL (- e _), com ou sem preenchimento =, e ignora espaços e quebras de linha. "Codificar Base64" gera o alfabeto padrão com preenchimento; para a forma segura para URL usada em JWTs, substitua + por -, / por _ e remova os sinais = do final. O texto é codificado em UTF-8 exatamente como foi digitado, então um espaço ou uma quebra de linha no final muda o resultado, e as quebras de linha da caixa são codificadas como LF.

Normalmente não. "Codificar URL" funciona como o encodeURIComponent do JavaScript: aplica a codificação percentual a todos os caracteres, exceto A–Z, a–z, 0–9 e - _ . ! ~ * ' ( ), de modo que os caracteres / ? & = : e # que estruturam uma URL também são codificados. Use-o para uma única parte, como o valor de um parâmetro de consulta. Os espaços viram %20 e os caracteres não ASCII são codificados como seus bytes UTF-8, então é vira %C3%A9.

"Decodificar URL" funciona como o decodeURIComponent do JavaScript: decodifica sequências de escape %XX e deixa o + inalterado, porque, na sintaxe geral de URLs (RFC 3986), + não representa um espaço. Dados de formulários HTML (application/x-www-form-urlencoded), formato usado em muitas query strings, codificam espaços como +, então, nesses dados, substitua cada + por um espaço antes de decodificar; um sinal de mais de verdade nesse formato é escrito como %2B e continua sendo decodificado corretamente. O erro aparece quando um % não é seguido de dois dígitos hexadecimais, como em 50% off, ou quando os bytes escapados não são UTF-8 válido, como em %E2%82.

Tokens na forma compacta de três partes header.payload.signature, usada por JWTs assinados (JWS), incluindo tokens sem assinatura com a parte da assinatura vazia. A parte da assinatura não é verificada, então um token decodificado não prova que ele é autêntico. Tokens criptografados (JWE) têm cinco partes, e o payload deles não pode ser lido sem a chave, então geram um erro de formato. Um cabeçalho ou payload que não decodifica de Base64 para JSON, ou um payload que é um valor simples, como uma string ou um número, em vez de um objeto JSON, gera a mensagem "Erro ao analisar o JWT". Inteiros maiores que 9.007.199.254.740.991 no cabeçalho ou no payload podem ser arredondados quando o navegador analisa o JSON, então IDs numéricos longos podem aparecer com os últimos dígitos diferentes.

Os valores são lidos como tempo Unix em segundos, como define o padrão JWT (RFC 7519), e exibidos em UTC e no seu horário local. "EXPIRADO" e "Ainda não é válido" comparam exp e nbf com o relógio do seu dispositivo no momento em que você clica em "Decodificar JWT", sem nenhuma tolerância para diferenças de relógio, então um relógio errado gera um status errado. Os servidores podem aceitar uma pequena margem, muitas vezes de no máximo alguns minutos, então, perto do horário de exp ou nbf, um servidor pode decidir de forma diferente do status mostrado aqui. Um horário escrito como string, como "1700000000", é indicado como um timestamp Unix numérico inválido.