Digital life
This code is not a secret
A string of random-looking letters can be a disguise, not a lock. Decode a harmless example, then learn what “URL-safe” actually promises.
Would you put a private message in a group chat if it looked like this?
TWVldCBhdCA3Lg==
It looks less readable than ordinary English. But you do not need a password, an account or a clever guess to recover it. The message is simply Meet at 7. We made up that sentence for this example; it is not somebody’s leaked conversation.
The difference matters when you are about to paste a screenshot, a support log or a mysterious string into a public post. Unreadable at a glance is not the same as private.
Try the reveal, with our harmless example
Open the English Base64 tool, paste TWVldCBhdCA3Lg== into the input, and choose Decode. The output should be Meet at 7. Keep the final period when comparing the result.
We did this in the live browser tool. It returned the sentence without asking for a secret. There was no cracking involved: the decoder followed the same public recipe used to write the encoded version.
Now choose Encode and enter Meet at 7. yourself. You should get the original scrambled-looking string back. For this controlled example, encoding and decoding are a round trip, not a locked door.
Use the supplied sample—not a real password, access token or private conversation—to try it.
A different alphabet is not a different level of privacy
Base64 is a way to express bytes using a limited set of text characters. It is useful when a system needs a textual representation of data. It does not decide who is allowed to read that data.
Our tool also has a URL-safe checkbox. That label sounds reassuring, but its job is narrower than it sounds: the variant uses - and _ where standard Base64 uses + and /. This tool also removes trailing = padding in that mode. Padding requirements depend on the format receiving the value; not every Base64 consumer accepts the same form.
Try 🌙 in Encode mode. With the checkbox off, the result is 8J+MmQ==. With it on, the result is 8J-MmQ. Both can be decoded by this tool to the same moon. Neither version is a protected message.
Three examples you can check without trusting a screenshot
These results use UTF-8 and contain no newline at the end of the input:
| Input | UTF-8 bytes | Standard Base64 |
|---|---|---|
Meet at 7. | 10 | TWVldCBhdCA3Lg== |
café | 5 | Y2Fmw6k= |
🌙 | 4 | 8J+MmQ== |
The moon looks like one symbol, but here it occupies four bytes before encoding. That is why counting visible symbols is not enough to predict the result. In these examples, the standard outputs have 16, 8 and 8 characters respectively. The change in length is formatting overhead, not evidence of stronger protection.
We checked these values with the site’s conversion functions and a separate Node implementation. That verifies these examples, not every possible input or the security of the whole website.
If decoding fails, do not assume you need a password
Base64 can represent bytes that are not a UTF-8 sentence. Our tool is a text decoder, not a universal file viewer.
For example, /w== represents a single byte with value 255. That byte is not valid UTF-8 text. The current tool shows a “This is not UTF-8 text” error instead of replacing the byte with �; it does not offer altered decoded text to copy. We checked this behavior in the conversion function and its tests, not with a real secret or binary file.
An error here does not mean the Base64 was encrypted or that a password is missing. It means this text tool cannot represent those decoded bytes as UTF-8. Keep the original data when investigating a format, and use a file-oriented decoder rather than this text box for binary data.
Before you press “share”
Ask a simpler question than “Does this look encrypted?”: Would I be comfortable sharing the decoded content?
For our invented meeting time, yes. For a real secret, changing its appearance is not enough. Do not paste it into an unfamiliar decoder to find out what it contains; use a harmless sample or an approved local workflow instead.
Our conversion functions run in the browser. That describes where those functions execute—not a guarantee about the entire page, your extensions, clipboard or device. We have not audited those boundaries here. The site’s privacy policy describes its broader data handling.
The useful habit is not to become suspicious of every long string. It is to stop treating a disguise as a lock.
Try it yourself
Sources and how we checked
We created three harmless examples and checked their UTF-8 bytes, standard Base64 and URL-safe forms against the current site functions and Node’s independent Buffer implementation. An earlier browser check reproduced the message and URL-safe moon. After the text decoder was changed, we rechecked that a non-UTF-8 byte is explicitly rejected in code and tests; this is not a security audit or a claim that every browser environment was retested.
- RFC 4648 — Base encodings, sections 4, 5 and 12
Standard and URL-safe alphabets, padding conventions and the explicit absence of confidentiality. · Accessed 9/27/2026 - MDN — Base64
The distinction between bytes, encoded text and JavaScript Unicode strings. · Accessed 9/27/2026
Checked by: Codex source review and browser reproduction · not a human security audit · 9/27/2026
Reopened RFC 4648 and MDN and rechecked the three synthetic UTF-8 examples with current functions and Node Buffer. A 2026-09-22 browser walkthrough reproduced the message and URL-safe moon; the new explicit invalid-UTF-8 error was checked against code/tests, not yet claimed as a fresh live browser result. No real secrets or network-confidentiality audit were involved.
Found a mistake? Send us the page URL and what needs correcting.