Qual padrão Base64 o Convertitive implementa?

O alfabeto padrão definido no RFC 4648 §4 (caracteres A–Z, a–z, 0–9, +, / com preenchimento =). A variante base64url do RFC 4648 §5 (+ → -, / → _, sem preenchimento) também é suportada e selecionada automaticamente quando o modo URL-safe está ativado. Ambas as variantes são totalmente especificadas no RFC 4648 (IETF, 2006).

O Convertitive verifica assinaturas JWT?

Não. O decodificador JWT analisa e exibe o cabeçalho e o payload por decodificação Base64url dos dois primeiros segmentos separados por pontos, conforme RFC 7519 §3. A verificação de assinatura requer o segredo de assinatura ou a chave pública, o que deliberadamente nunca solicitamos. Todo o processamento JWT é executado localmente no navegador; o token nunca sai do seu dispositivo.

Quais funções de hash o gerador de hash usa e elas são criptograficamente seguras?

O gerador usa SHA-1, SHA-256, SHA-384 e SHA-512 via Web Crypto API (window.crypto.subtle), cujas implementações são especificadas no NIST FIPS 180-4. Todo o processamento ocorre no navegador. SHA-1 foi descontinuado para resistência a colisões (ataque SHAttered, Stevens et al., 2017), mas ainda é usado em contextos legados como identificadores de objetos Git. Para integridade ou autenticação, use SHA-256 ou superior.

Como o gerador de UUID garante aleatoriedade?

UUIDs são versão 4 (aleatória) conforme especificado no RFC 9562 §5.4. Cada UUID é gerado usando window.crypto.getRandomValues(), um CSPRNG (gerador de números pseudoaleatórios criptograficamente seguro) fornecido pela fonte de entropia de nível do sistema operacional do navegador. Isso é diferente do Math.random(), que não é criptograficamente seguro. Os 122 bits aleatórios dão uma probabilidade de colisão de ~5 × 10⁻³⁶ por par.

Alguma ferramenta de código envia meus dados para um servidor?

Não. Codificação/decodificação Base64, análise JWT, geração de hash, geração de UUID e todos os outros utilitários de código são executados inteiramente no navegador via Web Crypto API e JavaScript padrão. Nenhuma carga útil é transmitida para nenhum servidor. Você pode verificar isso abrindo o DevTools do navegador → Rede e observando zero solicitações de saída ao usar essas ferramentas.

Methodology

Metodologia das ferramentas de código

Primitivas em conformidade com RFC, execução apenas no navegador, zero análise das cargas úteis.

By Buğra SözeriPublished May 14, 2026

O cluster de ferramentas de código oferece primitivas que todo desenvolvedor usa semanalmente — codificação Base64, decodificação JWT, geração de hash, UUIDs e utilitários de texto. Cada ferramenta é executada inteiramente no navegador: nenhuma carga útil sai do dispositivo.

Base64: RFC 4648, dois alfabetos

A codificação Base64 converte dados binários arbitrários em texto ASCII usando um conjunto de 64 caracteres imprimíveis. O RFC 4648 define dois alfabetos:

Padrão (§4): A–Z, a–z, 0–9, +, / com preenchimento =.
URL-safe (§5): substitui + por - e / por _, omite o preenchimento. Seguro em URLs e nomes de arquivos.

A ferramenta seleciona automaticamente o alfabeto URL-safe quando o toggle URL-safe está ativado. O padrão é o alfabeto completo com preenchimento.

JWT: decodificação, sem verificação

Um JWT (JSON Web Token) tem três partes separadas por pontos: header.payload.signature. O decodificador:

Divide na primeira e segunda ocorrências de ..
Aplica decodificação Base64url em cada parte.
Analisa como JSON e exibe o resultado formatado.
Ignora o terceiro segmento (assinatura) completamente.

A verificação requer o segredo de assinatura (para HMAC) ou a chave pública (para RSA/EC), que nunca solicitamos. O objetivo é inspeção, não validação — visualizar os campos exp, iat, sub e campos personalizados sem risco de expor credenciais.

Hashing: SHA-1, SHA-256, SHA-384, SHA-512

Implementado via window.crypto.subtle.digest() (Web Crypto API, FIPS 180-4). O output é formatado como hexadecimal em minúsculas — convencional para checksums de arquivos, checksums Git e saídas de ferramentas.

SHA-1 está incluído porque aparece em contextos legados (checksums Git, algumas assinaturas de certificados de CA raiz anteriores a 2016), mas o gerador exibe um aviso de descontinuação quando SHA-1 é selecionado.

Gerador de UUID (versão 4)

Formato: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, onde x é hexadecimal aleatório e y é um dígito do conjunto{8, 9, a, b}. Os 122 bits aleatórios vêm dewindow.crypto.getRandomValues(). O campo da versão (4) e a variante (10xxxxxx no byte de variante) são fixos conforme RFC 9562.

Pressupostos e limitações

Processamento apenas no navegador. Sem chamadas de servidor — não é possível fazer hash de arquivos maiores que a memória do navegador (~2 GB em prática).
Sem verificação de JWT. Inspecione e copie o payload, mas valide assinaturas no lado do servidor com a chave correta.
Apenas SHA-2 para nova segurança. SHA-1 está incluído por compatibilidade legada; use SHA-256 ou superior para novos casos de uso.
Aleatoriedade de UUID depende do CSPRNG do navegador. Em ambientes muito antigos sem Web Crypto, o gerador de UUID usa Math.random() como fallback com um aviso visível.

Frequently asked questions

Qual padrão Base64 o Convertitive implementa?: O alfabeto padrão definido no RFC 4648 §4 (caracteres A–Z, a–z, 0–9, +, / com preenchimento =). A variante base64url do RFC 4648 §5 (+ → -, / → _, sem preenchimento) também é suportada e selecionada automaticamente quando o modo URL-safe está ativado. Ambas as variantes são totalmente especificadas no RFC 4648 (IETF, 2006).
O Convertitive verifica assinaturas JWT?: Não. O decodificador JWT analisa e exibe o cabeçalho e o payload por decodificação Base64url dos dois primeiros segmentos separados por pontos, conforme RFC 7519 §3. A verificação de assinatura requer o segredo de assinatura ou a chave pública, o que deliberadamente nunca solicitamos. Todo o processamento JWT é executado localmente no navegador; o token nunca sai do seu dispositivo.
Quais funções de hash o gerador de hash usa e elas são criptograficamente seguras?: O gerador usa SHA-1, SHA-256, SHA-384 e SHA-512 via Web Crypto API (window.crypto.subtle), cujas implementações são especificadas no NIST FIPS 180-4. Todo o processamento ocorre no navegador. SHA-1 foi descontinuado para resistência a colisões (ataque SHAttered, Stevens et al., 2017), mas ainda é usado em contextos legados como identificadores de objetos Git. Para integridade ou autenticação, use SHA-256 ou superior.
Como o gerador de UUID garante aleatoriedade?: UUIDs são versão 4 (aleatória) conforme especificado no RFC 9562 §5.4. Cada UUID é gerado usando window.crypto.getRandomValues(), um CSPRNG (gerador de números pseudoaleatórios criptograficamente seguro) fornecido pela fonte de entropia de nível do sistema operacional do navegador. Isso é diferente do Math.random(), que não é criptograficamente seguro. Os 122 bits aleatórios dão uma probabilidade de colisão de ~5 × 10⁻³⁶ por par.
Alguma ferramenta de código envia meus dados para um servidor?: Não. Codificação/decodificação Base64, análise JWT, geração de hash, geração de UUID e todos os outros utilitários de código são executados inteiramente no navegador via Web Crypto API e JavaScript padrão. Nenhuma carga útil é transmitida para nenhum servidor. Você pode verificar isso abrindo o DevTools do navegador → Rede e observando zero solicitações de saída ao usar essas ferramentas.

Published May 14, 2026