Base64 Encoder
Encode text to Base64 format instantly. Perfect for embedding credentials in HTTP headers, generating data URIs, and building JSON payloads that contain binary content.
⏱ 10 min read · Complete guide below
Base64 Encoder
How Base64 Encoding Works
- 1Type or paste the text you want to encode. The encoder converts it to UTF-8 bytes first, then processes the bytes.
- 2The encoder groups bytes into sets of 3 (24 bits) and maps each 6-bit chunk to one of the 64 Base64 characters. Padding = characters are added if needed.
- 3The encoded string appears instantly. Click Copy to paste it into your code, config file, or HTTP header.
HTTP Basic Authentication and Base64
One of the most common developer uses of Base64 encoding is building HTTP Basic Auth headers. The Authorization header value is constructed as Basic <base64(username:password)>. For example, to authenticate as user alice with password secret, encode the string alice:secret to get YWxpY2U6c2VjcmV0, then send the header Authorization: Basic YWxpY2U6c2VjcmV0. Note that Basic Auth provides no security on its own — always use it over HTTPS.
What Base64 Is Actually For
Base64 exists to solve a specific problem: how to carry binary data through text-only channels. Many of the systems we rely on — email, JSON, XML, HTML, URLs, and various config formats — were designed to handle plain text and can corrupt or choke on arbitrary bytes. Base64 sidesteps this by re-expressing any data using just 64 safe, printable characters (A–Z, a–z, 0–9, plus + and /). It works by taking three bytes at a time (24 bits) and splitting them into four six-bit chunks, each mapped to one of those 64 characters, with = padding added at the end if the input length is not a multiple of three. The result is a text string that survives being pasted into an email body, embedded in a JSON payload, or dropped into a data URI without any bytes being mangled along the way.
Encoding Is Not Encryption
The single most important thing to understand about Base64 is that it provides no security whatsoever. It is a fully reversible, public transformation — anyone can decode a Base64 string back to its original content instantly, with no key or password. Because Base64 output looks scrambled to the human eye, it is sometimes mistaken for a way to hide data, which is a dangerous error: encoding a password in Base64 protects it exactly as much as writing it backwards would. This is precisely why HTTP Basic Authentication, which Base64-encodes your credentials, must always be used over HTTPS — the encoding is just a transport format, and the encryption that keeps the credentials private comes entirely from the secure connection. If you need to protect data, reach for real encryption, not Base64.
The Size Cost and When to Use It
Base64 buys interoperability at a price: the encoded output is about 33% larger than the original data, because every three bytes become four characters. That overhead is usually a fair trade for small payloads — embedding a tiny icon as a data URI to save an HTTP request, encoding credentials in a header, or putting a small file into a JSON body. It becomes a poor trade for large files, where the 33% inflation wastes bandwidth and storage; there, sending the raw binary over a channel that supports it is far better. As a rule of thumb, use Base64 when you must squeeze binary data through a text-only medium, and avoid it when a proper binary transport is available. For URL and filename contexts, note the related Base64url variant, which swaps + and / for - and _ so the output is safe to place in a URL.
Common Uses for Base64 Encoding
HTTP Basic Auth Headers
Build the Authorization header for HTTP Basic Auth by encoding "username:password" to Base64 and prefixing it with "Basic ". Required when calling APIs that use Basic Auth.
Embedding Images in CSS
Small images and icons can be embedded directly in CSS or HTML as data URIs — url('data:image/png;base64,...') — eliminating a separate HTTP request.
JSON API Payloads
JSON is text-only, so binary file content (PDFs, images) must be Base64-encoded before embedding in a JSON request body. Many document APIs expect this format.
Kubernetes Secrets
Values in Kubernetes Secret manifests must be Base64-encoded. Encode your credentials, certificates, or API keys here before pasting them into a secret YAML file.
JWT Generation
JSON Web Token headers and payloads are Base64url-encoded JSON objects. Encode your header and payload JSON here as the first step in manually constructing or testing a JWT.
SMTP / Email Attachments
Email attachments in MIME format must be Base64-encoded. If you are constructing raw SMTP messages or testing email delivery, encode the file content here.
A Worked Example: Encoding “Man” Step by Step
The best way to understand Base64 is to encode a short word by hand. Take the three-letter string Man. Each character has an ASCII byte value: M is 77, a is 97, and n is 110. Written in binary as eight bits each, that is 01001101, 01100001, and 01101110 — 24 bits in total, which is exactly three bytes, a perfect Base64 group.
Base64 now re-slices those 24 bits into four groups of six: 010011, 010110, 000101, and 101110. Read as numbers, those are 19, 22, 5, and 46. Looking each up in the Base64 alphabet — where 0–25 are A–Z, 26–51 are a–z, 52–61 are 0–9, 62 is + and 63 is / — gives T, W, F, and u. So “Man” encodes to TWFu. Notice there is no padding here, because the input was already a clean multiple of three bytes. Encode just “Ma” (two bytes) and you would get TWE= with one padding character; encode “M” alone and you would get TQ== with two. Working through this once makes the whole scheme click.
How Base64 Handles Unicode and Emoji
A frequent point of confusion is what happens with non-English text — accented letters, Arabic, Chinese, or emoji. Base64 itself only knows about bytes, not characters, so the real question is how your text becomes bytes in the first place. The answer is UTF-8, the dominant text encoding on the web. Before Base64 ever runs, this tool converts your text to its UTF-8 byte sequence, and then those bytes are encoded.
The consequence is that a single visible character can become several bytes. A plain ASCII letter is one byte, but an accented character is typically two, many Asian characters are three, and an emoji is often four. All of those bytes are then Base64-encoded normally. The crucial implication is on the decoding side: whoever decodes the Base64 must also interpret the resulting bytes as UTF-8 to recover the original text. Decode the bytes as some other encoding and the characters come out wrong — a classic source of “mojibake,” the garbled text you sometimes see when encodings are mismatched.
A Brief History and Its Variants
Base64 did not appear from nowhere. It grew out of the early internet's need to send binary files through email, which was strictly text-based. Earlier schemes like uuencode did a similar job, but Base64 — formalised as part of the MIME standard for email — became the durable winner because its 64-character alphabet was carefully chosen to survive virtually every text system in use. That reliability is why, decades later, it remains everywhere from web pages to cloud configuration.
Over time a few variants emerged for specific needs. The most important is Base64url, which swaps the URL-unfriendly + and / for - and _ so encoded values can sit safely in URLs and filenames — the variant used by JWTs and OAuth flows. Some contexts also use unpadded Base64, dropping the trailing = characters where the length can be inferred another way. These are all minor dialects of the same core idea, and knowing they exist saves confusion when a token looks almost but not quite like standard Base64.
Frequently Asked Questions
What is Base64 encoding?
Base64 encoding converts binary data (or text bytes) into a string of 64 printable ASCII characters: A–Z, a–z, 0–9, +, and /. The name comes from the 64-character alphabet used. It is a standard way to represent binary content — images, files, credentials — as plain text so it can be safely embedded in text-based formats like JSON, HTML, XML, and email.
How much larger does Base64 make my data?
Base64 encoding increases the size of the data by approximately 33%. This is because every 3 bytes of input (24 bits) are represented by 4 Base64 characters (6 bits each). A 1,000-byte string becomes roughly 1,333 characters in Base64. Padding = characters may add 0–2 extra characters to make the output length a multiple of 4.
Is Base64 a form of encryption?
No. Base64 is encoding, not encryption. It is trivially reversible — anyone can decode a Base64 string back to its original content with no key or password. Do not use Base64 to protect sensitive data. It provides no security, confidentiality, or integrity guarantees. It is purely a format transformation for interoperability.
What is the = sign at the end of Base64 output?
Base64 works on 3-byte groups. If the input is not a multiple of 3 bytes, padding = characters are appended to make the output length a multiple of 4. One = means one byte of padding was needed; == means two bytes. The padding is required by the standard — some systems omit it ("unpadded Base64"), but most expect it.
What is Base64url and when should I use it?
Base64url is a variant of Base64 used in URLs and file names. It replaces + with - and / with _ to avoid conflicts with URL special characters. It is used in JWTs, PKCE OAuth flows, and other web standards. If you are generating a JWT or a URL-safe token, use the Base64url variant rather than standard Base64.
Can I encode non-English or Unicode text?
Yes. This tool encodes the UTF-8 byte representation of your input text. Unicode characters — including accented letters, Arabic, Chinese, Japanese, emoji, and other non-ASCII content — are first converted to their UTF-8 byte sequences, then those bytes are Base64-encoded. The decoder must also know to interpret the output as UTF-8 to recover the original text correctly.
What is Base64 actually used for?
Its purpose is to carry binary data through text-only channels that would otherwise corrupt it. Systems like email, JSON, XML, HTML, and URLs were built for text, so raw bytes can break them. Base64 re-expresses any data using 64 safe printable characters so it survives being embedded in those formats. Common uses include HTTP Basic Auth headers, data URIs for embedding small images, binary content inside JSON payloads, Kubernetes secrets, and JWTs.
Is Base64 secure enough to hide a password?
No, absolutely not. Base64 is encoding, not encryption — it is fully reversible by anyone with no key or password, so it provides zero security. It only looks scrambled to the human eye. Encoding a password in Base64 protects it about as much as writing it backwards. This is why HTTP Basic Auth, which Base64-encodes credentials, must always run over HTTPS: the real protection comes from the encrypted connection, not the encoding. Use genuine encryption when you need confidentiality.
Why is Base64 output larger than the original data?
Because every three bytes of input are represented by four Base64 characters, the encoded result is roughly 33% larger than the original, plus up to two padding characters. This overhead is a reasonable trade for small payloads that must travel through a text channel, such as a small embedded image or a credential in a header. For large files it is wasteful, so when a proper binary transport is available it is better to send the raw bytes rather than Base64.
When should I use Base64url instead of standard Base64?
Use Base64url whenever the encoded value will appear in a URL or a filename. Standard Base64 uses the + and / characters, which have special meanings in URLs and can be unsafe in file paths. Base64url replaces + with - and / with _ (and often omits padding) so the output is safe in those contexts. It is the variant used in JSON Web Tokens (JWTs), PKCE OAuth flows, and many other web standards that pass encoded tokens through URLs.