Encoding(auto)
95 B → 128 BText to encode95 B
Base64
RW5jb2RlIGFueSB0ZXh0IOKAlCBpbmNsdWRpbmcgYWNjZW50cywg5L2g5aW9LCBhbmQgZW1vamkg8J+OiSDigJQgb3IgcGFzdGUgQmFzZTY0IHRvIGRlY29kZSBpdC4=Input95 B
Output128 B
Overhead+35%
StatusValid
Encode text to Base64 or decode it back, with the direction detected from what you paste. URL-safe output, optional padding, MIME line wrapping, and a data URI wrapper are all one switch each — and a malformed string is told what is wrong with it rather than silently producing nothing.
Step by step
01Paste either form
The direction is detected: text that looks like valid Base64 is decoded, anything else is encoded. Override it whenever the guess is wrong — a word like data can legitimately be both.
02Choose the alphabet
Standard Base64 uses + and /. URL-safe swaps them for - and _, which is what you need in a query string, a path segment, or a JWT — where the standard characters would be percent-encoded or misread.
03Decide about padding and wrapping
Padding with = keeps the length a multiple of four, which some strict decoders require and JWTs deliberately omit. Wrapping at 76 characters is what MIME asks for in email bodies.
04Wrap it as a data URI if it is going in a document
The data: prefix with a MIME type turns the string into something a browser will render directly — an inline stylesheet, a small file, a preview.
Worked example
Base64 is not compression and it is not encryption — it is a fixed re-encoding of three bytes into four printable characters. The arithmetic below is the whole mechanism.
Given
Three bytes, twenty-four bits, four characters
M a n
01001101 01100001 01101110 24 bits
010011 010110 000101 101110 regrouped into 6s
19 22 5 46 values
T W F u -> "TWFu"
3 bytes in, 4 characters out. Always.Every three bytes become four characters, so the output is exactly a third larger, and when the input is not a multiple of three the encoder pads to keep the block size — one = for two leftover bytes, two = for one. Nothing about this is secret: Base64 is trivially reversible by anyone, which is why finding credentials Base64-encoded in a config file is a finding, not a mitigation.
Before you use it
It is an encoding, not encryption
Anyone can decode it in one step, with no key and no effort. Base64 exists to move binary data through channels that only accept text — email bodies, JSON strings, URLs, HTML attributes. Credentials stored this way are stored in plain sight.
URL-safe is a different alphabet, not an option
Standard Base64 uses + and /, both of which mean something else in a URL. The URL-safe variant substitutes - and _ and usually drops the padding. A decoder expecting one alphabet will reject or mangle the other, which is why the switch exists on both sides here.
Padding is required by some decoders and forbidden by others
The = characters make the length a multiple of four. Strict decoders insist on them; JWTs and many URL-safe schemes deliberately strip them. If a string decodes here but not in your code, padding is the first thing to check.
Line wrapping is for email, and browsers ignore it
MIME requires Base64 broken at 76 characters in message bodies. HTML, CSS, and JSON ignore the newlines entirely, so one wrapped string can serve an email template and a stylesheet — but a strict command-line decoder may need the whitespace stripped first.
Text is encoded as UTF-8 bytes
Base64 operates on bytes, not characters, so text has to become bytes first. Accents, emoji, and non-Latin scripts encode correctly here because UTF-8 is used throughout — a mismatch in that step is the usual cause of mojibake after a round trip through another tool.
Everything runs locally
Encoding and decoding both happen in your browser, which matters because the strings people decode are usually tokens, credentials, and payloads pulled out of logs. Nothing is uploaded, and short inputs travel in a share link only if you choose to share one.
The judgement call
Base64 is one idea with several incompatible conventions layered on top. This is which to reach for.
A value in a query string or a path
URL-safe, unpadded
+ and / are reserved in URLs and = often is too. The URL-safe alphabet avoids percent-encoding entirely.
Inspecting a JWT segment
URL-safe, unpadded
JWT uses base64url with padding stripped. Standard decoding will fail on the same string.
An attachment or an email body
Standard, wrapped at 76
MIME asks for the standard alphabet and 76-character lines.
Inlining a small file in HTML or CSS
Data URI
The prefix carries the MIME type, which is what tells the browser how to read the bytes.
Storing a password or an API key
Not Base64
It hides nothing from anyone. Use a secret manager, or hashing where you only need to verify.
Making a payload smaller
Wrong tool
Base64 makes data a third larger. Compress first if size matters, then encode if the channel demands text.
Reference
FAQ
Paste it in — a string that looks like valid Base64 is decoded automatically. Both alphabets are accepted, whitespace and line breaks are ignored, and missing padding is tolerated, so a JWT segment or a wrapped email body decodes without cleaning it up first.
No. It is a reversible encoding with no key, and anyone can decode it in a single step. Its purpose is to move binary data safely through text-only channels such as email bodies, JSON, and URLs. Credentials that are merely Base64-encoded are stored in plain sight.
A variant that swaps + and / — both reserved in URLs — for - and _, and usually drops the = padding. It is what JWTs and most token formats use. A standard decoder fed a URL-safe string will typically fail or produce the wrong bytes, so the alphabet has to match on both sides.
The three usual causes are a truncated string, a mismatched alphabet, and a character lost in copying. Valid Base64 uses only its 64-character alphabet and has a length that is a multiple of four once padded — if either test fails, the tool names which one rather than showing you nothing.
Because it encodes every three bytes as four printable characters — a fixed 33% expansion, plus a padding character or two. That is the price of representing arbitrary bytes using only characters that survive text-based channels intact.
No. Encoding and decoding both run in your browser, which matters because the strings people decode are usually tokens, credentials, and payloads pulled out of logs. Nothing is transmitted or stored.
Encoding and decoding both run in your browser. Nothing is uploaded, logged, or retained — which matters when the string is a token or a credential.
Keep going
Image Base64 Converter
The same encoding for image files, with data URI output.
JWT Decoder
Decode all three segments of a token and read the claims.
URL Encoder
The other encoding that gets confused with this one.
JSON Formatter
Format the payload once it comes back out.