Encoders & Decoders
Tools for encoding and decoding text between formats. All processing happens in your browser, so your data is never uploaded.
- CSR DecoderPaste a certificate signing request or an X.509 certificate to read what is inside it: subject, alternative names, key algorithm and size, validity dates, extensions and fingerprints. Everything is decoded in your browser and nothing is ever uploaded.
- Base64 Encoder & DecoderEncode text to Base64 or decode it back. Unicode is handled correctly, so Japanese, Chinese, Korean and emoji all round-trip without corruption.
- URL Encoder & DecoderPercent-encode text for use in a URL, or decode it back. Choose whether you are encoding one query value or an entire URL, because the two need different escaping.
- Hash & HMAC GeneratorType or paste text to see its MD5, SHA-1, SHA-256 and SHA-512 hashes at once, or switch to HMAC to sign it with a secret key. Everything runs in your browser, so neither your text nor your key leaves your device.
- JWT DecoderPaste a JWT to read its header and payload and see when it expires. Decoding happens entirely in your browser, so the token never leaves your device.
- JWT GeneratorBuild a JWT payload, pick an algorithm and sign it with your secret. Signing happens entirely in your browser, so the secret never leaves your device.
Choose an encoding tool
Use Base64 to move bytes through a text channel and URL encoding to put a value safely inside an address. Use the hash generator for checksums and for HMAC signatures, where a shared secret proves who produced the message.
Use the JWT decoder to read a token's claims and, with the secret, check its signature; the JWT generator to mint one for a test; and the CSR decoder to see the names and key a certificate request actually asks for before sending it to an authority.
Four jobs that look alike and are not
Encoding rewrites data into a safer alphabet and is fully reversible by anyone: Base64 and percent-encoding both belong here. Hashing is one-way and keyless, so it proves that two inputs match without revealing either. Signing adds a secret, which is what turns a message into evidence of who sent it. Inspecting simply decodes structure that is already public, which is what the JWT and CSR readers do.
Confusing the first with the third is the expensive mistake. A Base64 payload looks scrambled and protects nothing; anyone who has it can read it in a second, which is easy to demonstrate by pasting one into the decoder here.
The recurring failure is layers
Encoding is not idempotent. Escape a value twice and %20 becomes %2520, a quote becomes a doubly backslashed quote, and a payload that should hold an object holds a string of JSON instead. It happens whenever application code encodes something a framework was going to encode anyway.
The fix is to remove one of the two steps rather than to decode twice at the other end, which only moves the bug. Decoding one layer at a time in these tools tells you how many layers there actually were, which is usually the fastest way to find which component added the extra one.
Think about what you are pasting
Everything here runs in your browser, so nothing you paste is uploaded or logged. That is worth knowing because the material that lands in these tools is rarely neutral: a CSR carries internal hostnames and an organisation, a JWT carries user identifiers and scopes, and a hash input may be the secret itself.
Two habits are still worth keeping. Verify a signature with a test secret rather than a production one where you can, and never paste a private key into any web page, including this one - a CSR is safe to share, the key that signed it is not.