🔄 Base64 Encoder & Decoder

Last updated: January 18, 2026

Base64 Encoder & Decoder

Encode/decode standard & URL-safe Base64 — JWT segments, Basic Auth headers, API payloads. 100% browser-side, nothing leaves your machine.

Encoded output will appear here...
Quick Examples
Hello, World! username:password {"sub":"user123"} Bearer token

How to Use Base64 Encoding in API Development and JWT Debugging

Every developer working with REST APIs, authentication headers, or JWTs runs into Base64 sooner or later. The format looks cryptic at first glance — a wall of letters, numbers, and the occasional == at the end — but it follows a completely deterministic algorithm that you can reverse in your browser without any server involvement. Understanding what Base64 is, where it appears, and how to decode it quickly turns a frustrating debugging session into a five-second lookup.

What Base64 Actually Is (and Is Not)

Base64 is an encoding scheme, not an encryption algorithm. This distinction matters enormously in security contexts. When you encode a string in Base64, you are not hiding it — you are translating binary data into a set of 64 printable ASCII characters (A–Z, a–z, 0–9, plus + and /, with = for padding). The sole purpose is safe transport of arbitrary bytes through systems that only handle text reliably, such as HTTP headers, JSON fields, or email bodies.

The algorithm works in 3-byte chunks. Each chunk of 3 bytes (24 bits) maps to 4 Base64 characters (6 bits each). If the input is not a multiple of three bytes, padding characters (= or ==) are appended. This is why encoded output is always roughly 33% larger than the original and always ends in 0, 1, or 2 equals signs.

Standard Base64 vs URL-safe Base64

Standard Base64 uses + and / as the 62nd and 63rd characters. These are problematic in URLs because + means a space in query strings and / is a path delimiter. URL-safe Base64 (defined in RFC 4648 §5) replaces them with - and _ respectively, and typically omits the trailing = padding.

This distinction bites developers constantly. If you paste a standard Base64 string into a URL parameter without encoding it, the + characters silently become spaces on the server side and the entire value is corrupted. The tool above auto-detects which variant you are working with based on which characters appear in the input, and applies the correct decoding path in both cases.

Decoding JWT Tokens for Debugging

JSON Web Tokens are the most common place developers encounter Base64 in the wild. A JWT is three URL-safe Base64 segments separated by dots. The first segment is the header (algorithm and token type), the second is the payload (claims like subject, issuer, expiry), and the third is the cryptographic signature.

The header and payload are just URL-safe Base64-encoded JSON. You can decode them instantly with any Base64 tool. The Inspect JWT mode of this tool does exactly that: splits on the dots, decodes each segment, pretty-prints the JSON, and extracts the standard claims (iat, exp, sub, iss, aud) to show you at a glance whether the token has already expired and who it was issued for.

A critical point: decoding the payload is not the same as verifying the token. Anyone can craft a JSON payload and Base64-encode it. The signature segment exists to prove the token was issued by someone with the right secret or private key. Use this tool to inspect what a JWT contains during debugging — never to decide whether to trust it. Signature verification belongs on your backend.

Building and Verifying Basic Auth Headers

HTTP Basic Authentication sends credentials in the Authorization header in the format Basic <base64(username:password)>. For example, if your username is apiuser and password is secret123, the header value is Basic YXBpdXNlcjpzZWNyZXQxMjM=. The colon between username and password is part of the Base64 input — a detail that trips up many developers building API clients from scratch.

When an API request fails with a 401, one fast check is to copy the Authorization header value, strip the Basic prefix, and drop the remainder into a decoder. If you see the correct username:password pair, the header is formed correctly and the problem is elsewhere. If you see garbage or an error, the encoding step has a bug.

Unicode and Non-ASCII Content

Standard btoa() in browsers only accepts strings where every character is within the Latin-1 range (code points 0–255). Try to encode a string containing Hindi, Chinese, or emoji and you get a DOMException: The string contains characters outside of the Latin1 range error. The solution is to UTF-8 encode the string first, then Base64-encode the resulting bytes.

The correct approach is: btoa(unescape(encodeURIComponent(str))) for encoding, and decodeURIComponent(escape(atob(b64))) for decoding. This tool applies exactly this pattern, so you can safely encode strings in any language without hitting the Latin-1 trap.

Inspecting Binary Payloads in API Responses

Many APIs return binary data — images, PDFs, or encrypted blobs — as Base64-encoded strings inside JSON responses. This avoids the need for multipart encoding and keeps the response in a single JSON structure. When you encounter a field like "thumbnail": "iVBORw0KGso..." in an API response, that is a Base64-encoded PNG starting with the PNG magic bytes (iVBORw0KGso decodes to the standard PNG header).

Decoding such a field in this tool gives you the raw binary content as a text string, which is mostly unprintable. For actual binary inspection you would need a hex editor or a dedicated binary viewer. However, for text-based binary formats like PEM certificates or SSH public keys, decoding the Base64 layer immediately gives you readable content with clear structure markers like -----BEGIN CERTIFICATE-----.

Common Mistakes and How to Avoid Them

The most frequent error is padding mismatch. Some generators omit the trailing = characters (especially in JWT and OAuth contexts), and naive decoders fail because the input length is not a multiple of 4. Always add = padding back before decoding: compute 4 - (length % 4) modulo 4 and append that many equals signs.

The second common mistake is whitespace. Base64 strings in configuration files, PEM certificates, and email bodies often include line breaks every 76 characters. Strip all whitespace before decoding. The third mistake is confusing URL-safe and standard variants — mixing -_ and +/ characters in the same string will produce incorrect output or an outright error.

Using a browser-based tool like this one eliminates all three classes of errors automatically. The normalisation logic handles padding, strips whitespace, and converts between variants before attempting to decode, giving you the correct result without requiring you to remember these edge cases during a time-pressured debugging session.

FAQ

Is Base64 a form of encryption?
No. Base64 is an encoding scheme, not encryption. It converts binary data into printable ASCII characters for safe transport through text-based systems, but it provides zero confidentiality. Anyone who sees a Base64 string can decode it instantly. Never use Base64 alone to protect sensitive data — use proper encryption (AES, RSA, etc.) for that purpose.
Why does my JWT have three parts separated by dots?
A JWT consists of three URL-safe Base64 segments: the header (algorithm and token type), the payload (claims such as user ID, expiry, roles), and the signature. The first two are simply Base64-encoded JSON and can be decoded by any Base64 decoder. The third segment is a cryptographic signature that can only be verified using the correct secret or public key — decoding it without verification proves nothing about the token's authenticity.
What is the difference between standard Base64 and URL-safe Base64?
Standard Base64 uses + and / as special characters and = for padding. URL-safe Base64 (RFC 4648 §5) replaces + with - and / with _ so the output can be included in URLs and filenames without percent-encoding. Padding (=) is also typically omitted in URL-safe variants. JWTs, OAuth tokens, and most modern web APIs use URL-safe Base64.
Why does encoding a string with non-English characters sometimes fail?
The browser's native btoa() function only accepts Latin-1 characters (code points 0–255). Strings containing Unicode characters outside that range (like Chinese, Arabic, Hindi, or emoji) trigger a DOMException. The fix is to UTF-8 encode the string first using encodeURIComponent/unescape before passing it to btoa(). This tool handles that conversion automatically.
How do I decode a Basic Auth header to see the username and password?
Take the Authorization header value, remove the leading 'Basic ' prefix (including the space), then decode the remaining Base64 string. The result will be in the format username:password — the username and password are separated by a colon. This is useful for verifying that your API client is sending the correct credentials when debugging 401 errors.
Does this tool send my data anywhere?
No. All encoding and decoding happens entirely in your browser using JavaScript's built-in btoa() and atob() functions. Nothing is sent to any server. This makes the tool safe to use with sensitive values like API keys, JWT tokens, and credentials during local development and debugging sessions.