Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 to text. Unicode and URL-safe variants supported.
How to decode a Base64 string from an API response
Paste the string above and read the decoded text. Base64 turns arbitrary bytes into 64 printable characters so they survive transports that expect text: headers, JSON string fields, URLs, email bodies. Every three bytes of input become four characters of output, which is why an encoded value is always about a third larger than the original.
Three shapes account for most Base64 you meet while testing an API: a Basic authorization header, an embedded file or image in a JSON field, and the header and payload of a JWT. The first two decode here directly. For the third, use a JWT decoder instead: it splits the three segments for you and labels the claims.
Standard versus URL-safe Base64
There are two alphabets, and picking the wrong one is the most common cause of a value that decodes to nonsense.
| Variant | Characters 62 and 63 | Padding | Used in |
|---|---|---|---|
| Standard | + and / | = kept | HTTP headers, email, most APIs |
| URL-safe | - and _ | usually stripped | URLs, query strings, JWT segments, filenames |
If a value contains a hyphen or an underscore it is almost certainly URL-safe. If it contains a plus sign and arrived through a URL, suspect that the plus was silently converted to a space somewhere in transit: that is a real and frequent bug, because in a query string a plus means space unless it is percent-encoded.
Why your Base64 string will not decode
- Wrong alphabet: a URL-safe string fed to a standard decoder, or the reverse.
- Missing padding. Standard Base64 pads to a multiple of four with equals signs; a value copied from a URL often has them stripped.
- Whitespace or line breaks introduced by copying out of a terminal or an email header that wraps at 76 characters.
- A plus sign that became a space in a query string.
- The value was double-encoded. Decoding once yields another Base64 string, which is a sign of a serialisation bug worth filing.
- It was never Base64. Hex and Base58 both look similar at a glance and decode to nothing sensible.
Building a Basic authentication header
Basic auth is the credentials joined by a colon, Base64-encoded, and prefixed with the word Basic. Encoding admin:hunter2 gives YWRtaW46aHVudGVyMg==, and the header reads Authorization: Basic YWRtaW46aHVudGVyMg==. A password containing a colon still works, because only the first colon separates the two fields.
Worth saying plainly in any security-related test report: this is encoding, not encryption. Anyone who can see the header can recover the password instantly. Basic auth is only acceptable over TLS, and a Basic header in a log file or a bug report screenshot is a leaked credential.
Base64 and non-ASCII text
Base64 encodes bytes, not characters, so the encoding of any text depends on the character encoding used first. The same string encoded as UTF-8 and as UTF-16 produces completely different Base64. When a decoded value shows question marks or broken glyphs, the Base64 step is usually innocent and the character encoding upstream is the defect. This is a good reason to include at least one non-Latin string in any test set that round-trips through Base64.
Frequently asked questions
Is Base64 encryption?
No, and this matters. Base64 is a reversible encoding with no key, so anyone can decode it. It protects nothing. Data described as being protected by Base64 in a design document is a finding, not a control.
Why does my Base64 string end with one or two equals signs?
That is padding. Base64 works in blocks of three input bytes, and when the input length is not a multiple of three the output is padded to a multiple of four characters. One equals sign means two bytes in the final block, two equals signs mean one byte.
Can I Base64-encode an image?
Yes, which is how data URIs work. Remember the roughly 33% size increase, and that a large embedded image bloats a JSON payload and a test fixture considerably. For API testing it is usually better to reference a file than to inline it.
What is the difference between Base64 and Base64url?
Base64url replaces plus with hyphen and slash with underscore, and usually drops the equals padding, so the value can travel in a URL or filename without percent-encoding. JWT segments use Base64url. The decoded bytes are identical; only the alphabet differs.
Why did my Base64 value change when it went through a URL?
Because standard Base64 contains plus and slash, and in a query string an unencoded plus means a space. Either percent-encode the value or use the URL-safe alphabet. This is a good test case for any endpoint that accepts an encoded token as a query parameter.
Is it safe to decode a Base64 string in an online tool?
Only if the tool does not transmit it, since Base64 values routinely contain credentials, tokens and personal data. This encoder and decoder runs entirely in your browser and sends nothing, which you can confirm in the DevTools Network tab.