Encoder / Decoder guide
What Base64, URL encoding and HTML entities are for, how XGM Encoder / Decoder converts UTF-8 text and number bases, and why encoding is never encryption.
What Base64 does
Base64 (RFC 4648) takes bytes three at a time, splits the 24 bits into four 6-bit groups and maps each group to one of 64 characters: A–Z, a–z, 0–9, + and /. When the input length is not a multiple of three, = padding fills the last group. The output is about 33% larger than the input, but it contains only characters that survive systems built for text.
Common uses include email attachments (MIME), data URIs that embed small images in HTML or CSS, binary fields in JSON, HTTP Basic authentication headers and the parts of JSON Web Tokens. In each case the goal is transport, not secrecy.
How to use Base64 in the Encoder
- Open the Encoder / Decoder.
- Choose Encode to turn text into Base64, or Decode to turn Base64 into text.
- Tick "URL-safe alphabet" for Base64url, which uses
-and_and omits padding. - Paste your input; the result updates in your browser and can be copied.
Text is encoded as UTF-8, so characters such as ş, ü or emoji are handled correctly. When decoding produces bytes that are not valid UTF-8 text, for example an image or compressed data, the tool reports the content as binary instead of showing unreadable characters.
URL encoding, HTML entities and number bases
The Encoder / Decoder has three more modes next to Base64. URL percent-encodes text: choose a single query value or path segment (encodeURIComponent, which also escapes &, = and /) or a whole URL (encodeURI, which keeps the characters that structure it). Decoding can treat + as a space, as HTML forms send it.
HTML entities escapes the five characters that change HTML structure (<, >, &, " and '), optionally every non-ASCII character too, and decodes named and numeric references. Number base converts integers of any size between binary, octal, decimal, hexadecimal and base 36 without rounding, and accepts 0x, 0o and 0b prefixes.
| Job | Mode |
|---|---|
| Binary data in JSON, email or a data URI | Base64 |
| A value in a query string | URL, query value |
| Showing user text inside HTML | HTML entities |
| Reading a hex dump or bit mask | Number base |
Standard Base64 and Base64url
| Variant | Characters 62 and 63 | Padding | Used in |
|---|---|---|---|
| Base64 | + and / | = required | MIME email, data URIs, most APIs |
| Base64url | - and _ | Usually omitted | JWTs, URLs, file names, WebAuthn |
+ and / have special meanings in URLs and = in query strings, so standard Base64 inside a URL needs percent-encoding. Base64url avoids that. Decoders for one variant usually reject the other, which is a frequent cause of "invalid Base64" errors when a JWT part is pasted into a standard decoder.
Standard: +/+/Pz8=
URL-safe: -_-_Pz8Base64 is not encryption
Base64 hides nothing. Anyone who sees YWRtaW46c2VjcmV0 can decode it to admin:secret in a second, which is exactly what an HTTP Basic authentication header contains. Configuration files and logs that store "encoded" passwords in Base64 store them in plain text for practical purposes.
Encoded secrets are still secrets
Authorization: Basic YWRtaW46c2VjcmV0
# decodes to admin:secret; only TLS protects it in transitWhere you meet Base64
| Place | What it looks like | Variant |
|---|---|---|
| Email attachments | Blocks of 76-character lines under Content-Transfer-Encoding: base64 | Standard, wrapped |
| Data URIs | data:image/png;base64,iVBORw0KGgo… | Standard |
| JSON Web Tokens | Three dot-separated parts starting with eyJ | Base64url |
| HTTP Basic authentication | Authorization: Basic … | Standard |
| Kubernetes secrets | Values in data: fields of Secret manifests | Standard |
| DKIM keys and certificates | The p= value in DKIM records, PEM blocks | Standard |
| Subresource Integrity | integrity="sha384-…" | Standard |
The prefix eyJ is a useful hint: it is the Base64 encoding of {", so strings starting with it are usually encoded JSON, very often a JWT. Similarly, PEM files are Base64 between -----BEGIN and -----END lines, and data URIs always contain ;base64, before the payload.
Kubernetes secrets are a well-known example of Base64 being mistaken for protection. The values in a Secret manifest are only encoded; anyone who can read the manifest can read the secret. Encryption at rest and access control on the cluster are what actually protect them.
Base64 on the command line and in code
# Linux / macOS
printf '%s' 'Hello' | base64 # SGVsbG8=
printf '%s' 'SGVsbG8=' | base64 --decode
# JavaScript (UTF-8 safe)
btoa(String.fromCharCode(...new TextEncoder().encode('Grüße')))
# Python
python3 -c "import base64; print(base64.urlsafe_b64encode(b'Hello').decode())"Most languages ship Base64 in their standard library, so there is rarely a reason to implement it yourself. Pay attention to which variant a function produces: many libraries have separate functions for standard and URL-safe Base64, and some add or strip padding differently. When two systems disagree about a value, compare the variant and padding first.
The browser's btoa works on Latin-1 strings only and throws for other characters, which is why the example converts text to UTF-8 bytes first. Line breaks are another trap: some tools wrap Base64 output at 76 characters, as MIME requires, and other decoders refuse those line breaks.
Troubleshooting decode errors
| Symptom | Cause | Fix |
|---|---|---|
| Invalid character | Base64url input in a standard decoder, or stray spaces | Tick URL-safe, or replace - and _ with + and / |
| Invalid length | Padding removed | Add = until the length is a multiple of 4, or use URL-safe mode |
| Unreadable output | The data is binary (image, compressed, encrypted) | Save the bytes to a file instead of reading them as text |
| Wrong accented characters | Text was encoded in another character set | Decode with the original encoding, or re-encode as UTF-8 |
| Extra characters at the start | A data URI prefix such as data:image/png;base64, | Remove everything up to and including the comma |
For JWTs, use the JWT Decoder instead, which splits the token and decodes each part as Base64url. For values in URLs, the URL Encoder handles percent-encoding such as the %2B that appears when + passes through a query string on https://www.example.com/?token=.
FAQ
Is Base64 encryption?
No. It is a reversible encoding without a key. Anyone can decode it.
Why is Base64 output longer than the input?
Every 3 bytes become 4 characters, so the size grows by about a third, plus padding.
What are the = signs at the end?
Padding that makes the length a multiple of 4. One = means the last group had two bytes, == means one byte.
What is Base64url?
A variant that uses - and _ instead of + and / and usually omits padding, so values can be used in URLs and file names without escaping.
Does the tool handle emoji and accented characters?
Yes. Text is encoded as UTF-8 before Base64, and decoding reads UTF-8 back.
Is my input uploaded?
No. Encoding and decoding happen in your browser.
Can I decode an image?
The tool shows text results. Base64 that decodes to binary is reported as binary; save such data to a file with a command-line tool to view it.
Why does my decoded text have strange characters?
The original text was probably in a different character encoding, or the data is binary. Check how it was produced.
Is Base32 or hex better than Base64?
They trade size for readability. Hex doubles the size but is simple and case-insensitive; Base32 avoids ambiguous characters and case issues; Base64 is the most compact of the three.
Why do some Base64 strings contain line breaks?
MIME email wraps Base64 at 76 characters per line. Remove the line breaks before decoding with tools that expect a single line.
Should I embed images as Base64 data URIs?
Only very small ones. Base64 adds a third to the size and prevents separate caching; regular image files are better for anything larger than a small icon.