Base64 Encode & Decode Online — Text, Files, JWT & URL-Safe

What Is Base64 — and Why Does It Exist?

Base64 is a binary-to-text encoding scheme. It takes raw binary data — bytes that could include null bytes, control characters, or any value from 0 to 255 — and represents them using only 64 safe, printable ASCII characters: A through Z, a through z, 0 through 9, plus + and /, with = for padding.

It exists because many systems that move data around — email servers, HTTP headers, JSON parsers, XML processors, databases — were designed for text. They may corrupt, truncate, or misinterpret raw binary data. Base64 sidesteps this entirely by using only characters that every text-based system handles safely.

The trade-off: Base64 increases data size by approximately 33%. For every 3 bytes of input, you get 4 characters of output. That overhead is acceptable in nearly every use case where it is applied, because the alternative is not transmitting the data at all.

How to Encode Text to Base64 (Step-by-Step)

The most common operation: you have a string and you need its Base64 representation. This comes up constantly in API development, config generation, and credential setup.

Quick examples: The string Hello World encodes to SGVsbG8gV29ybGQ=. The string user:pass (an HTTP Basic Auth credential pair) encodes to dXNlcjpwYXNz. Any UTF-8 text, including non-ASCII characters and emoji, encodes correctly — the tool uses TextEncoder to handle full Unicode before encoding.

How to Decode a Base64 String

Decoding is just as common as encoding — you receive a Base64 string in an API response, a config file, or a header, and you need to read the actual value.

How to Decode a JWT Token — and Check If It's Expired

JWT (JSON Web Token) is the most common authentication token format in modern web applications. Every JWT has three Base64-encoded sections separated by dots: header.payload.signature. The header and payload are readable — they contain the algorithm, user ID, roles, permissions, and expiry time. The signature cannot be decoded without the secret key.

Developers need to decode JWTs constantly — when debugging authentication failures, checking which user ID a token belongs to, or investigating why a token is being rejected as expired.

JWT Standard Claims — What Each Field Means

JWT payloads contain claims — key-value pairs that describe the token. Some are standardised (registered claims); others are custom fields added by your application. Here are the standard claims you will encounter most often:

The exp claim is the most important to check when debugging authentication failures. It is a Unix timestamp (seconds since Jan 1, 1970). The JWT Decoder converts it to your local timezone automatically and flags whether the token is currently expired.

Standard vs URL-Safe Base64 — When to Use Each

There are two variants of Base64, and using the wrong one causes subtle, hard-to-debug errors — especially in JWTs, OAuth flows, and URL query parameters.

The decoder at ToolLance handles both automatically — it normalises- back to + and _ back to / before decoding, and adds padding if missing. You never need to manually convert between variants before pasting.

How to Convert a File or Image to Base64

The File tab converts any file — image, PDF, font, audio, or any other format — to its Base64 representation. For images, it also generates the complete data: URI, which you can paste directly into CSS or HTML without hosting the image anywhere.

When to use inline Base64 images vs hosted images: Inline Base64 makes sense for small assets (icons under 2KB, SVG illustrations, spinner animations) where eliminating the extra HTTP request is worth the 33% size increase. For larger images, hosting is almost always better — Base64 cannot be cached by the browser independently, and inline Base64 in CSS blocks stylesheet parsing.

Base64 Size Increase — What to Expect

Base64 always increases data size by approximately 33%, because every 3 bytes of binary data become 4 characters. Here is the exact relationship for common sizes:

The ToolLance encoder shows the exact byte count, output character count, and percentage size increase for every string you encode — so you always know the real overhead.

Where Base64 Actually Appears — Real-World Use Cases

Base64 is everywhere in modern development. Here are the places you will encounter it most often, grouped by context:

How to Decode a Kubernetes Secret

Kubernetes stores all secret values as Base64 in etcd. When you run kubectl get secret <name> -o yaml, every value under the data: key is Base64-encoded. Here is the workflow to decode one:

1. Run kubectl get secret <secret-name> -n <namespace> -o yaml
2. Find the field you want to read. It will look like: password: cGFzc3dvcmQxMjM=
3. Copy the value after the colon (e.g. cGFzc3dvcmQxMjM=)
4. Paste it into the Decode tab — the plain text value appears instantly

Alternatively, from the command line: kubectl get secret <name> -o jsonpath="{.data.password}" | base64 --decode. The online tool is faster for occasional lookups when you do not have kubectl context configured locally.

How to Decode an HTTP Basic Auth Header

HTTP Basic Authentication encodes credentials as username:password in standard Base64 and places them in the Authorization header:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

To decode: copy everything after Basic (the space matters — do not include it), paste it into the Decode tab, and you get username:password.

Security note: Basic Auth credentials are only encoded, not encrypted. Anyone who intercepts the header can decode it instantly. Always use HTTPS when transmitting Basic Auth headers — the TLS layer provides the actual encryption.

Is Base64 Encryption? No — Here's the Difference

This is one of the most common misconceptions about Base64. It is encoding, not encryption, and the distinction matters enormously for security decisions.

• Encoding transforms data into a different representation using a publicly known, reversible algorithm. No key, no secret. Anyone can reverse it. Base64 is encoding.
• Encryption transforms data using a secret key such that the output is computationally infeasible to reverse without that key. AES, RSA, and ChaCha20 are encryption algorithms.

If you Base64-encode a password and store it, you have not secured it — you have just made it slightly less obvious. Anyone with access to the encoded string can decode it in one step with any Base64 tool.

For actual security: hash passwords with bcrypt, Argon2, or scrypt. Encrypt sensitive data with AES-256-GCM or use an established library. Base64 has no role in protecting data — only in representing it.

Why Base64 Strings End with = or == (Padding Explained)

Base64 processes input in 3-byte chunks and produces 4-character output. When the input length is not a multiple of 3, padding is added to keep the output length a multiple of 4:

• Input length divisible by 3 → no padding
• Input leaves 1 byte remaining → two = padding characters
• Input leaves 2 bytes remaining → one = padding character

URL-safe Base64 omits padding entirely. This is why JWT tokens do not end with = — the Base64 sections are URL-safe and unpadded. When decoding a JWT, padding must be added back before decoding, which the ToolLance decoder handles automatically.

Privacy — What Happens to Your Data

Everything in the ToolLance Base64 tool runs locally in your browser. No data is sent to any server. This matters because:

• Kubernetes secrets — actual production credentials should never be pasted into a tool that uploads them
• JWT tokens — contain user IDs, roles, and session information that belongs to your users
• Basic Auth headers — directly contain plaintext usernames and passwords
• API keys and private tokens — frequently appear in Base64-encoded environment variables and configs

The tool uses JavaScript's built-in btoa(), atob(), TextEncoder, and FileReader APIs — everything stays in your browser tab. You can verify this by opening your browser's Network tab and confirming no requests are made when you encode or decode.

Related Developer Tools

Working with JWT tokens in a production API? You will likely also need to encode query parameters — the URL Encoder / Decoder handles percent-encoding for special characters in URLs, which is different from Base64 but equally essential. If you are inspecting API responses and need to format or validate JSON payloads, the JSON Formatter works well alongside the JWT decoder. Working with environment variable files or YAML config? The Diff Checker makes it easy to spot changes between encoded and decoded config blocks.