Base64 represents binary data using a limited set of printable characters. It is commonly found in email attachments, data URLs, API payloads, and configuration values that need to travel through text-only systems.
You can experiment with ordinary text in the QuickToolsBox Base64 Encoder and Decoder. Processing happens in your browser.
A simple Base64 example
The text below:
Hello, world!becomes:
SGVsbG8sIHdvcmxkIQ==The encoded value looks unfamiliar, but it is not secret. Anyone can decode it without a password or key.
Why Base64 exists
Computers can store any sequence of bytes, while older protocols and text fields may accept only a restricted character set. Base64 maps every three input bytes to four printable characters. The standard alphabet contains uppercase letters, lowercase letters, digits, +, and /. The = character may be added as padding when the byte count is not divisible by three.
Because three bytes become four characters, Base64 normally increases the data size by about one third, before any additional formatting or transport overhead.
How to encode and decode text
- Open the Base64 tool.
- Enter ordinary text and choose Encode.
- Copy the encoded result.
- To reverse it, paste a Base64 string and choose Decode.
- Confirm that the decoded text uses the expected character encoding, usually UTF-8.
If decoding fails, check whether the value is URL-safe Base64, has missing padding, contains whitespace, or was copied incompletely.
Base64 is not encryption
Encryption protects information with a key. Base64 only changes its representation. It must never be used as the only protection for passwords, API secrets, personal information, or authentication tokens.
A useful rule is simple: if the recipient can use the data, the recipient can decode Base64. Treat the encoded value with the same sensitivity as the original.
Standard and URL-safe Base64
Standard Base64 uses + and /. Those characters can have special meanings in URLs. URL-safe Base64 replaces them with - and _, and some implementations omit trailing padding. JWT components use this URL-safe form.
When two systems disagree, verify which alphabet and padding rules each one expects. Do not assume every Base64-looking string follows the same variant.
Common uses
- Embedding a small image in a CSS or HTML data URL
- Carrying binary content inside JSON or XML
- Encoding email attachments in MIME messages
- Representing certificate or key material in text files
- Transferring bytes through systems that are not binary-safe
Embedding large files as Base64 can make pages and payloads inefficient. For ordinary web images, a separate optimized file is often easier to cache and maintain.
Common mistakes
Encoding text twice
If decoding produces another Base64-looking string, the original may have been encoded more than once. Decode only when you understand the expected data flow.
Confusing bytes and characters
Non-ASCII text must first be converted to bytes using an encoding such as UTF-8. Different character encodings can produce different byte sequences and therefore different Base64 output.
Sharing encoded secrets
Base64 does not redact or anonymize data. Avoid posting encoded tokens in tickets, chat messages, screenshots, or public repositories.
Frequently asked questions
Why does Base64 end with equals signs?
Padding marks the incomplete final group of input bytes. Depending on the variant, padding can sometimes be omitted.
Can I Base64-encode an image?
Yes. The image bytes can be encoded and used in a data URL, but the result is larger than the original and may not be appropriate for large images.
How can I tell whether a string is Base64?
The alphabet and length offer clues, but they do not prove it. Many ordinary strings happen to use the same characters. The strongest check is to decode the value and verify that the result matches the expected format.