Three encodings, zero secrecy
I keep these three conversions on one page because they get used as if they were cousins of encryption. They are not. Base64 makes bytes survive a text channel. URL encoding makes a value survive a query string. HTML entities make characters survive a markup parser. Anyone who can see the output can reverse it. If a WhatsApp forward says the API key is “encrypted in Base64,” the key is in the message.
Use this when a JWT segment looks like noise, when a redirect URL ate a plus sign, or when a CMS is printing raw < into a page. Do not use this as a vault, a password wrapper, or a way to hide a PAN in a URL. Encoding is dressing. The bytes are still right there.
Worked example: Base64 of hello, and the padding
hello encodes to aGVsbG8=. The trailing = is padding so the length is a multiple of 4. Decode it and you have hello again. hello world becomes aGVsbG8gd29ybGQ=. JWT uses base64url, which swaps +// for -/_ and often drops padding. If you decode a JWT payload with this button and it errors, you may need to restore = or translate the URL alphabet first. HTTP Basic auth is base64(user:pass) — that is transport convention, not confidentiality. Anyone on the hop who can read the header can decode it.
Worked example: URL encoding a GST query
This button is encodeURIComponent, not encodeURI. A space becomes %20, not a plus (plus is application/x-www-form-urlencoded in some form bodies). GST 18% becomes GST%2018%25 — the percent sign itself must be encoded or the next parser eats two hex digits. a@b.com becomes a%40b.com. A full URL should not be pushed through this button as a whole if you only meant to escape the query value: https:// would turn into https%3A%2F%2F and your redirect now looks like a relative path. Nested redirects that encode twice produce %2520. Decode once per layer, not “until it looks nice.”
Worked example: HTML entities versus XSS
Encode <script>alert(1)</script> and you should see <script> style entities. That is what you want before stuffing untrusted text into HTML. It is not a substitute for a framework’s auto-escape, and it does not help if you then assign the decoded string to innerHTML. Quotes: " in an attribute is the difference between a value and a breakout. This encoder maps & < > ". It does not invent a full HTML5 named-entity table. Decode uses the browser’s own entity parser — fine for & and decimal numeric entities, not a promise about every legacy named entity in a 2009 feed.
Mistakes that look like cryptography
Calling Base64 “encrypted” in a spec. URL-encoding a value that will be decoded by a server that expects form-urlencoded plus-for-space, so %20 and + disagree. Decoding untrusted Base64 into the page and executing it. Pasting a 40 MB file into the box until the tab dies — btoa holds the whole string in memory. Unicode: this encoder UTF-8-wraps text before btoa, so Devanagari and emoji round-trip; raw binary still is not a file picker.
Questions
If I Base64 a PAN, is it hidden from the query log?
No. Decode is one button. A PAN in a URL is still a PAN, just uglier. Do not put it in a URL.
Why did JWT payload decode fail here?
JWTs use base64url: hyphen/underscore, often no padding. This button is standard Base64 (plus/slash, equals padding). Translate the alphabet or restore = first.
Space → %20 or space → +?
This page uses encodeURIComponent, so %20. Form bodies sometimes use +. Mixing them is how search queries grow pluses.
encodeURI versus encodeURIComponent?
encodeURI leaves :/?&= intact for a whole URL. This tool encodes those too, which is correct for a single parameter value and wrong for a whole URL.
Will HTML-encoding stop XSS if I use innerHTML?
Not if you decode first or interpolate into a script context. Prefer textContent or your framework’s default escaping.
Why does emoji Base64 look longer than the characters?
UTF-8. One emoji is often four bytes; Base64 expands those bytes by about 4/3. The length is the bytes, not the graphemes.