Encode or decode text using popular formats like Base64, URL, HTML, ROT13, Caesar cipher, hashing (SHA), and JWT decoding. Fast, secure, and fully client-side.
Developers frequently need to encode or decode a string mid-task: building an API request with a Base64 auth header, debugging a URL-encoded query parameter, escaping HTML entities in a template, or inspecting the claims inside a JWT. Having every format in one tab saves constant tool-switching.
This tool follows the standard Base64 alphabet defined in RFC 4648, so output matches what any other RFC-compliant encoder or decoder produces. One clarification worth stating plainly: Base64, ROT13, and the Caesar cipher are encodings and simple ciphers, not encryption - they make text unreadable to a casual glance, but anyone can reverse them without a secret key.
For SHA-1 and SHA-256, hashing is one-way by design (you can't decode a hash back to the original text) - it's meant for verifying data integrity, not encoding text for later retrieval.
A browser-based text encoder and decoder handles Base64, URL encoding, HTML entities, ROT13, Caesar cipher, JWT decoding, and SHA-1/SHA-256 hashing - all in one place, without any server uploads. Every operation runs locally using standard browser APIs, keeping tokens, headers, and passwords completely private.
Paste or type the text you want to encode, decode, or hash.
Select encoding, decoding, cipher, hashing, or JWT decoding mode.
Convert the text instantly using the selected operation.
Copy the result to clipboard or download it as a text file.
Encode credentials for Basic Auth headers with Base64.
Decode URL-encoded query strings from analytics tools.
Escape HTML entities for safe template rendering.
Decode a JWT to inspect its claims during API or auth debugging.
Generate a SHA-256 hash to verify two files or strings are identical.
Best For
Text
HelloBase64
SGVsbG8=Switching the mode to Base64 Decode and pasting SGVsbG8= back in reverses this exactly. This is standard Base64 (RFC 4648) - not the URL-safe Base64URL variant used in JWTs, which uses - and _ instead of + and /.
Text
hello world & moreURL Encoded
hello%20world%20%26%20moreThis uses component encoding, so every character that isn't safe inside a single query parameter gets escaped - including the & - not just spaces. That's different from encoding a full URL, where & separates parameters and should stay as-is.
Text
<div class="test">HTML Encoded
<div class="test">The five characters that have special meaning in HTML - &, <, >, ", ' - are replaced with named entities so the string renders as visible text instead of being parsed as markup.
Text
HelloROT13
UryybROT13 shifts each letter 13 places, which makes it its own inverse - running ROT13 on Uryyb returns Hello. It has no security value; it's a convention for hiding spoilers or puzzle answers from a casual glance.
Text (shift 3)
HelloCaesar Cipher
KhoorUnlike ROT13's fixed shift of 13, the Caesar cipher's shift amount is adjustable. Like ROT13, it's fully reversible without a secret key, so it's a teaching tool, not a way to protect data.
Text
HelloSHA-256 (hex)
185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969The output is always a 64-character hexadecimal string, regardless of input length, and it can't be turned back into the original text - hashing is one-way, useful for confirming two pieces of text match without comparing them directly.
JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cDecoded JSON
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
}The tool reads the header and payload - both are just Base64-encoded JSON - and prints them together. It doesn't verify the signature (the third, dot-separated part), since that requires the issuer's secret or public key.
Decode a JWT to inspect its claims, or decode a Base64 Basic Auth header, while debugging an API integration - no server round trip required.
HTML-encode user-generated content before inserting it into markup, or URL-encode a value before appending it to a query string, so the result can't be misread as syntax.
Generate a SHA-256 hash of each and compare the two hashes instead of diffing the content character by character.
ROT13 is a long-standing convention for hiding spoilers or answers in forum posts and puzzles - reversible by anyone, which is exactly the point for this use case and not for anything that needs to stay secret.
Problem
Solution
All three are reversible with no secret key - anyone can decode a Base64 string or reverse a Caesar shift. They represent or lightly obscure text; they don't protect confidential data.
Problem
Solution
This tool decodes standard Base64 (using + and /), not the URL-safe variant (using - and _) that JWTs and some web contexts use. Replace - with + and _ with / - and restore any missing = padding - before decoding a Base64URL string here.
Problem
Solution
Hashing is one-way by design - there's no "decode hash" operation, here or anywhere, because the original text can't be reconstructed from the digest. Hashing confirms data matches; it doesn't store or retrieve it.
Problem
Solution
JWT Decode expects exactly three dot-separated segments (header.payload.signature). A truncated token, an opaque API key, or a plain access token that isn't a JWT fails with a generic "Invalid input" message rather than a specific explanation.
If a Base64 string contains - or _ instead of + or /, it's Base64URL - convert it to standard Base64 first, or the decode will fail. See the Common Mistakes note above for the exact character swap.
SHA-1 is included for compatibility with older systems, but it has known collision weaknesses. SHA-256 is the safer default when you just need to confirm two pieces of text match.
The JWT Decode output is JSON, but it's easiest to read one field at a time - paste the header or payload from the output into the JSON Formatter for a larger, syntax-checked view.
Hashing supports SHA-1 and SHA-256 only. If you need to match an existing MD5 checksum, this tool won't generate one.
There's no option to produce the URL-safe Base64URL variant directly. If you need Base64URL output for a URL or a JWT segment, encode as standard Base64 here, then manually replace + with -, / with _, and strip the = padding.
Input is a single textarea. There's no file upload option, so paste the text content directly rather than uploading a file.
Whether a Base64 string has bad padding, a URL string is malformed, or a JWT has fewer than three segments, invalid input shows the same "Invalid input for selected operation" message rather than pinpointing which rule was violated.
Encoding (Base64, URL, HTML, ROT13, Caesar) represents or lightly transforms text and is always reversible. Hashing (SHA-1, SHA-256) produces a fixed-size fingerprint of the input and is one-way by design.
| Encoding | Hashing | |
|---|---|---|
| Reversible? | Yes - decode to get the original text back | No - a hash can't be turned back into the original text |
| Output length | Varies with input length | Fixed length regardless of input (SHA-256 is always 64 hex characters) |
| Typical purpose | Represent text safely in another format - a URL, HTML, a text-only field | Verify two pieces of data are identical, or detect changes |
Which should you use?
Neither encoding nor hashing is encryption - encoding has no secret key, and hashing can't be reversed even with one. Use encoding to transform text for a specific format, and hashing to verify integrity, not to protect confidential data.
Both replace certain characters with a safe representation, but for different destinations - a URL versus HTML markup - and mixing them up produces output that doesn't work in either context.
| URL Encoding | HTML Encoding | |
|---|---|---|
| Protects | Query strings and other URL components | Text inserted into HTML markup |
| Trigger characters | Spaces, &, ?, =, and other URL-reserved characters | <, >, &, and quote characters |
| Example | A space becomes %20 | < becomes < |
Which should you use?
Encode a value for whichever context it's headed into next - a query parameter needs URL encoding, text rendered inside HTML needs HTML encoding, and neither substitutes for the other.
Text encoder visitors are usually mid-task with one specific string to convert. The most common points of confusion are whether these operations are secure, and why a Base64 or JWT string sometimes fails to decode - both are answered below.
No. Base64 is a reversible encoding scheme, not encryption - anyone can decode a Base64 string back to its original text with no key required. It's used to safely represent binary or special-character data in text-only formats like URLs, JSON, or email. If you need to keep data confidential, use actual encryption; Base64 alone provides no protection against reading the content.
Two common causes: the string uses Base64URL characters (- and _) instead of standard Base64 (+ and /) - this happens with JWTs and some web-safe encodings - or the string is missing its padding (= characters) at the end. This tool decodes standard Base64; if your string came from a URL-safe context, replace - with + and _ with / before decoding.
Yes, for the header and payload - both are just Base64-encoded JSON, readable by anyone without any key. What you can't do without the issuer's secret (or public key, for asymmetric algorithms) is verify the signature - so you can read a JWT's claims but can't confirm it hasn't been tampered with. This tool decodes the readable parts only; it does not attempt signature verification.
URL encoding (percent-encoding) replaces characters that aren't allowed in a URL - like spaces and & - with a % followed by a hex code, so a space becomes %20. HTML encoding replaces characters with special meaning in HTML markup - like < and & - with named entities such as < and &, so they display as text instead of being parsed as markup. They solve different problems: encoding a URL parameter with HTML entities won't make it a valid URL, and vice versa.
Yes. Every operation here - Base64, URL, HTML, ROT13, Caesar cipher, SHA hashing, and JWT decoding - runs entirely in your browser using JavaScript and the Web Crypto API. Nothing is sent to a server, which you can confirm yourself by opening your browser's DevTools Network tab before processing a token.
Encoding the word "Hello": Base64 gives SGVsbG8=, ROT13 gives Uryyb, and Caesar cipher with the default shift of 3 gives Khoor. For URL encoding, a space becomes %20. For HTML entity encoding, < becomes <. SHA-256 hashing always outputs a fixed 64-character hexadecimal string regardless of input length - useful for confirming two pieces of text are identical without comparing them character by character.
Leave your email so we can prioritize similar tools and updates.
Trending tools will appear as visitors explore the catalog.
Your recently visited tools will show up here.