Base64 Encoder and Decoder
Encode any text to Base64 or decode it back instantly in your browser — a free tool for developers, no upload.
Your text stays on your device
Nothing to delete afterwards
Built for decoding credentials
Works in every modern browser
How it works
- 1
Paste your text
Plain text to encode, or a Base64 string to decode.
- 2
Pick the direction and alphabet
Encode or decode, standard or URL-safe, depending on where the result is going.
- 3
Copy the result
Take it into a header, a data URI, a config value, or a request.
Why use this tool
Both alphabets
Standard Base64 and the URL-safe variant, so a token that must survive a query string does.
Padding handled either way
Input with or without trailing `=` decodes, and you choose what the output carries.
UTF-8 done correctly
Arabic, Turkish, and emoji round-trip intact instead of decoding into replacement characters.
Instant in both directions
Encode and decode in the same place, without switching tools halfway through a debugging session.
Nothing is uploaded
The conversion happens in your browser — a token you paste never reaches a server.
Free, no account
No signup, no watermark, no cap on how much you convert.
Base64 is not encryption, and treating it as such is a real vulnerability
This is the most important thing to understand about the format, and it is misunderstood constantly. Base64 has no key, no secret, and no security property whatsoever. It is a public, reversible mapping that anyone can undo in one step — which is exactly what this page does. Yet Base64 shows up regularly as a substitute for protection: passwords stored Base64-encoded in a database, API keys "obfuscated" in a config file, personal data encoded in a cookie so it "does not look like anything". None of that is hidden. It is merely written in a different alphabet, and any person or scanner that finds it reads it immediately. If the goal is that someone must not be able to read a value, you need encryption or hashing, and Base64 is neither.
What it is actually for: getting bytes through text-only channels
Base64 solves a specific and unglamorous problem. Many systems accept only printable text: email bodies, JSON string fields, HTTP headers, XML documents, URLs. Hand any of them raw binary — an image, a compressed archive, an encryption key — and something in the path will mangle it, because bytes that happen to look like control characters or line endings get rewritten in transit. Base64 sidesteps this by re-expressing arbitrary bytes using 64 characters that every system agrees to leave alone. That is why an email attachment is Base64 inside the message, why an inline image in CSS is a `data:` URI, and why a binary certificate is delivered as a PEM block. The format is a transport wrapper, not a storage format and not a security measure.
It costs you a third more bytes, and sometimes that matters
The arithmetic is fixed: every three bytes of input become four characters of output, so encoded data is about 33 percent larger than what went in, before padding. Most of the time this is irrelevant. It stops being irrelevant when people inline images as `data:` URIs in CSS or HTML to save an HTTP request. A 90 KB image becomes 120 KB of characters, and unlike a real image file it cannot be cached separately, cannot be lazy-loaded, and blocks the stylesheet that contains it. For a small icon that is a fair trade. For a photograph it is usually a mistake that shows up later as a slow first paint. If you are encoding something to embed it, check what the size does before committing.
The URL-safe alphabet exists because three characters break URLs
Standard Base64 uses `+`, `/`, and `=`, and all three mean something else in a URL. A plus sign is read as a space in query strings, a slash is a path separator, and an equals sign separates a parameter from its value. Send a standard-encoded token through a URL and it arrives corrupted, often in a way that only shows up for some inputs — which is why "it works in my API client but breaks in the browser" is such a common report. The URL-safe variant fixes this by substituting `-` for `+` and `_` for `/`, and usually dropping padding entirely. JWTs use it, as do most modern token formats. The two alphabets are not interchangeable: decoding a URL-safe string with a strict standard decoder fails, so match the variant to where the value travelled.
What the trailing equals signs are doing
Padding is the part everybody notices and nobody is sure about. Because encoding works on groups of three bytes, an input whose length is not a multiple of three leaves a partial group, and `=` characters pad the output to a multiple of four. One equals sign means the input ended with two leftover bytes; two mean it ended with one. That is all they carry — they are a length hint, not data. In practice decoders disagree about whether they are required: some reject unpadded input outright, some accept it, and the URL-safe convention usually omits padding because `=` is awkward in a URL. If a value fails to decode somewhere and looks fine here, mismatched padding expectations are worth checking before anything more exotic.
Why decoding locally matters more here than almost anywhere else
Look at what people actually paste into a Base64 decoder. It is an `Authorization: Basic` header, which contains a username and password separated by a colon. It is the payload half of a JWT, which carries a user identifier and often an email address. It is a connection string, an API key, a session cookie, a certificate. The whole reason someone reaches for a decoder is that they are holding a value they cannot read, and values you cannot read are overwhelmingly credentials. Pasting those into a hosted decoder hands a working secret to a third party, over a channel that leaves no trace. This tool converts inside the page and transmits nothing, which you can confirm in the Network tab of your developer tools — and for this particular format, that is not a nicety.
Common mistakes to avoid
- Using Base64 to hide something. There is no key and no secret — anyone can decode it in one step; if a value must not be readable, it needs encryption or hashing, not a different alphabet.
- Sending a standard-encoded value through a URL. The `+`, `/`, and `=` characters all mean something else there; use the URL-safe alphabet or the value arrives corrupted for some inputs and not others.
- Inlining a large image as a `data:` URI. Encoding adds about a third to the size, and the result cannot be cached separately or lazy-loaded — fine for a small icon, costly for a photograph.
- Assuming padding is optional everywhere. Some decoders require the trailing `=`, some reject it; if a value decodes here and fails elsewhere, check the padding expectation before looking for exotic causes.
- Pasting an Authorization header or a JWT into a hosted decoder. Those values are live credentials, and the paste leaves no trace that you sent them; decode locally.
How it compares
| Aspect | This tool | Online decoders | A command line |
|---|---|---|---|
| Content sent to a server | Never | Usually yes | No |
| URL-safe alphabet | Yes | Varies | Needs a flag |
| UTF-8 handled correctly | Yes | Varies | Yes |
| Setup required | None | None | A terminal |
| Account or signup | Not needed | Often required | Not needed |
| Price | Free | Free / paid tiers | Free |
Features
Encode and decode
Both directions in one place, with the input and output side by side.
URL-safe variant
The `-` and `_` alphabet used by JWTs and anything that travels in a URL.
Optional padding
Emit or strip the trailing `=` characters to match what the receiving system expects.
Full Unicode support
Text is encoded as UTF-8 first, so non-Latin scripts survive the trip.
Handles large input
Long strings convert without an upload or a size cap.
Invalid input flagged
A string that is not valid Base64 says so instead of returning quiet nonsense.
Nothing to install
No command line, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no content tracking and no third-party upload.
Who uses it
Developers
Reading an auth header or a token payload while debugging, without handing it to a third party.
Security engineers
Inspecting an encoded value found in a log, a cookie, or a configuration file.
API integrators
Building or checking a Basic auth header before sending a request against it.
Front-end developers
Producing a `data:` URI for a small inline asset and seeing what it costs in size.
Frequently Asked Questions
No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.
Yes — completely free, with no account and no limits.