Paste text to get Base64, or paste Base64 to get the text back. Unicode is handled properly: accented letters, Japanese, and emoji all survive the round trip, where tools built on the browser's raw btoa call either throw or quietly corrupt them. Since nothing is transmitted, this is safe for the thing people most often decode: a JWT or an API token they would rather not paste into someone else's server.
Most online text tools send whatever you paste to a server, run the work there, and send a result back. Your words sit in someone else's logs, backups and databases, and you have to trust a privacy policy.
Local-first means the opposite: the whole tool is downloaded to your browser and runs on your own device. Nothing you type is transmitted anywhere: not to us, not to anyone. There is no server that could receive it, which is a stronger guarantee than a promise not to look.
Three consequences worth knowing:
You do not have to take that on trust. Open your browser's developer tools, watch the network panel, and type: nothing appears in it.The network's verify page walks through the same check on every Jamuny tool.
A round trip that survives non-ASCII
Jamun is a deep purple fruit 🫐
SmFtdW4gaXMgYSBkZWVwIHB1cnBsZSBmcnVpdCDwn6uQ
The browser's built-in btoa function only accepts Latin-1 characters. Give it an emoji or a Japanese character and it throws an exception, and tools built directly on it either fail or silently mangle the input.
The fix is to convert the text to UTF-8 bytes first and encode those, which is what happens here. That makes the round trip lossless for any text you can type, and it is why the example above comes back exactly as it went in.
This is the single most consequential misunderstanding about Base64, and it has caused real breaches. It is a reversible encoding with no key. Anyone who has the encoded string can decode it instantly, including with this page.
It exists to carry binary data through channels that only accept text: email attachments, data URIs, JSON string fields, HTTP headers. Storing a password Base64-encoded is storing it in plain text with an extra step, and anything treating a Base64 string as a secret is treating obscurity as security.
A JWT is three Base64-encoded parts separated by dots, so you can decode each part here. Two differences catch people out: JWTs use base64url, which replaces + with - and / with _, and the trailing = padding is usually stripped.
Paste one segment at a time and add any missing = characters if the decode fails. If you are working with tokens regularly, the dedicated JWT decoder handles the segments, the padding and the signature check in one step.
Worth remembering while you are doing it: decoding a token tells you what it claims, not whether those claims are true. Only checking the signature does that, and no amount of Base64 decoding will.
Because the browser's built-in btoa only accepts Latin-1 characters. Anything outside that range has to be converted to UTF-8 bytes first, which is what happens here, so the round trip is lossless.
No, and this matters. It is a reversible encoding with no key, so anyone can decode it instantly. It exists to move binary data through text-only channels, not to protect anything.
You can decode its parts, though a JWT uses base64url, which swaps two characters and usually drops the padding. Paste a single segment at a time and add any missing = padding if the decode fails.