Base64 Encoder/Decoder
Encode, decode, and inspect Base64 and Data-URIs with zero latency. Features Smart Payload auto-detection, real-time JSON Web Token (JWT) inspector, Data-URI image builder, Base64 bloat auditor, and RFC 4648 URL-Safe master toggle with 100% client-side privacy.
Online ToolsStandard RFC 4648 Base64 64-Character Alphabet Index
Complete mapping of 6-bit binary sequences to standard Base64 and URL-Safe character sets.
| Value (Decimal) | 6-Bit Binary | Base64 Char | URL-Safe Char | ASCII Hex |
|---|---|---|---|---|
| 0 | 000000 | A | A | 0x41 |
| 1 | 000001 | B | B | 0x42 |
| 2 | 000010 | C | C | 0x43 |
| 3 | 000011 | D | D | 0x44 |
| 4 | 000100 | E | E | 0x45 |
| 5 | 000101 | F | F | 0x46 |
| 6 | 000110 | G | G | 0x47 |
| 7 | 000111 | H | H | 0x48 |
| 8 | 001000 | I | I | 0x49 |
| 9 | 001001 | J | J | 0x4A |
| 10 | 001010 | K | K | 0x4B |
| 11 | 001011 | L | L | 0x4C |
| 12 | 001100 | M | M | 0x4D |
| 13 | 001101 | N | N | 0x4E |
| 14 | 001110 | O | O | 0x4F |
| 15 | 001111 | P | P | 0x50 |
| 16 | 010000 | Q | Q | 0x51 |
| 17 | 010001 | R | R | 0x52 |
| 18 | 010010 | S | S | 0x53 |
| 19 | 010011 | T | T | 0x54 |
| 20 | 010100 | U | U | 0x55 |
| 21 | 010101 | V | V | 0x56 |
| 22 | 010110 | W | W | 0x57 |
| 23 | 010111 | X | X | 0x58 |
| 24 | 011000 | Y | Y | 0x59 |
| 25 | 011001 | Z | Z | 0x5A |
| 26 | 011010 | a | a | 0x61 |
| 27 | 011011 | b | b | 0x62 |
| 28 | 011100 | c | c | 0x63 |
| 29 | 011101 | d | d | 0x64 |
| 30 | 011110 | e | e | 0x65 |
| 31 | 011111 | f | f | 0x66 |
| 32 | 100000 | g | g | 0x67 |
| 33 | 100001 | h | h | 0x68 |
| 34 | 100010 | i | i | 0x69 |
| 35 | 100011 | j | j | 0x6A |
| 36 | 100100 | k | k | 0x6B |
| 37 | 100101 | l | l | 0x6C |
| 38 | 100110 | m | m | 0x6D |
| 39 | 100111 | n | n | 0x6E |
| 40 | 101000 | o | o | 0x6F |
| 41 | 101001 | p | p | 0x70 |
| 42 | 101010 | q | q | 0x71 |
| 43 | 101011 | r | r | 0x72 |
| 44 | 101100 | s | s | 0x73 |
| 45 | 101101 | t | t | 0x74 |
| 46 | 101110 | u | u | 0x75 |
| 47 | 101111 | v | v | 0x76 |
| 48 | 110000 | w | w | 0x77 |
| 49 | 110001 | x | x | 0x78 |
| 50 | 110010 | y | y | 0x79 |
| 51 | 110011 | z | z | 0x7A |
| 52 | 110100 | 0 | 0 | 0x30 |
| 53 | 110101 | 1 | 1 | 0x31 |
| 54 | 110110 | 2 | 2 | 0x32 |
| 55 | 110111 | 3 | 3 | 0x33 |
| 56 | 111000 | 4 | 4 | 0x34 |
| 57 | 111001 | 5 | 5 | 0x35 |
| 58 | 111010 | 6 | 6 | 0x36 |
| 59 | 111011 | 7 | 7 | 0x37 |
| 60 | 111100 | 8 | 8 | 0x38 |
| 61 | 111101 | 9 | 9 | 0x39 |
| 62 | 111110 | + | - | 0x2B |
| 63 | 111111 | / | _ | 0x2F |
Mathematical Architecture of Base64 Padding (=)
Why padding occurs and how 24-bit alignment dictates the terminal equal signs.
The 3-Byte to 4-Character Alignment Mechanism
Base64 transforms groups of three 8-bit octets (24 bits total) into four 6-bit indices (24 bits total). When the input byte sequence is not evenly divisible by 3, the final chunk requires special padding treatment.
When the byte count divides evenly by 3, exactly 4 Base64 characters are generated per 3 bytes. No padding character (=) is added.
8 bits are available. The encoder takes 6 bits for the first char, then 2 remaining bits padded with 4 zero bits for the second char. Two padding characters (==) are appended to complete the 4-character quad.
16 bits are available. The encoder extracts two 6-bit characters (12 bits), leaving 4 bits padded with 2 zero bits for the third char. Exactly one padding character (=) is appended.
The +33.3% Overhead Penalty in Modern Web Architecture
Base64 maps 3 bytes of raw binary into 4 ASCII bytes, inherently inflating uncompressed payload sizes by exactly 33.33%. In web performance, while inlining eliminates an HTTP roundtrip, payload parsing and lack of browser image cache can degrade Total Blocking Time (TBT).
Developer Best Practices: When to Inline vs When to Link
Favicons, micro SVGs, and critical placeholder pixels benefit from Data URIs by eliminating subresource roundtrips during initial paint.
With modern multiplexed protocols, asset inlining is largely deprecated for medium or large graphics due to cache poisoning and byte bloat.
For basic auth headers and JWT claim inspection, Base64 offers transport safety across text protocols, never cryptographic confidentiality.
How to Use the Base64 Encoder & Decoder (Step-by-Step)
Master text encoding, binary file conversion, URL-safe data transfer, and JWT token inspection.
Select Operation Mode or Use Auto-Detect
Choose 'Auto-Detect' for automatic input classification, or select 'Encode', 'Decode', 'JWT Inspector', or 'Data-URI Builder' from the top toolbar to suit your specific workflow.
Enter Text, Paste Hashes, or Upload Files
Type or paste UTF-8 strings, Base64 hashes, or JWT tokens into the terminal input. Alternatively, drag and drop files (images, SVGs, documents) to generate Data URIs instantly.
Configure RFC 4648 URL-Safe Mode
Toggle the 'URL-Safe' switch to replace '+' with '-' and '/' with '_', and strip trailing '=' padding characters, ensuring seamless compatibility with web URLs and query parameters.
Inspect Decoded Payloads & Live Previews
When analyzing JWTs, view structured headers, claims, and token expiration status. When converting images, preview visual output alongside ready-to-use HTML and CSS snippets.
Audit Payload Size & Bloat Overhead
Use the built-in Bloat Auditor to monitor the exact +33.3% encoding overhead and raw vs. encoded byte sizes, helping you decide whether inline embedding is optimal.
Copy to Clipboard or Download Output
Click 'Copy to Clipboard' for instant use in your code or API requests, or download the output as a standalone file. All processing is 100% private and runs client-side.
Frequently Asked Questions (FAQ)
Technical and practical answers for software engineers, security professionals, and web developers.
Q:What is Base64 encoding and why is it used?
Base64 is a binary-to-text encoding algorithm specified in RFC 4648. It translates raw binary data into a set of 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). It is widely used to transmit binary assets—such as images, cryptographic keys, and digital signatures—over text-based protocols like HTTP, SMTP email, JSON, and XML without data corruption caused by control characters.
Q:What is the difference between Standard Base64 and URL-Safe Base64?
Standard Base64 (RFC 4648 §4) uses '+' and '/' along with '=' padding. In URLs and HTTP query parameters, '+' is often interpreted as a space and '/' functions as a path delimiter, causing decoding errors. URL-Safe Base64 (RFC 4648 §5) solves this by replacing '+' with '-' (hyphen) and '/' with '_' (underscore), and typically omits trailing '=' padding.
Q:Why does Base64 increase data size by ~33%?
Base64 encodes every 3 bytes (24 bits) of binary input into 4 printable ASCII characters (32 bits), because each Base64 character represents only 6 bits of information. This mathematical ratio of 4 to 3 results in an exact 33.33% increase in uncompressed payload size, plus up to 2 bytes of padding characters if needed.
Q:What do the equal signs (=) at the end of a Base64 string mean?
The equal sign '=' is a padding character used to align data to 24-bit boundaries. When the input byte length is not divisible by 3, zero bits are appended to fill the final 6-bit quantum. One '=' is appended if 2 bytes remained (requiring 3 characters + 1 pad), while '==' is appended if 1 byte remained (requiring 2 characters + 2 pads).
Q:How does the JWT Inspector work and is my token secure?
A JSON Web Token (JWT) comprises three parts separated by periods: Header, Payload, and Signature. Our inspector splits the token, decodes the Base64URL-encoded header and payload, and displays claims, expiration status, and algorithms. Because all parsing runs client-side in your browser, your tokens, secrets, and session cookies never leave your machine.
Q:When should I embed images as Base64 Data URIs vs. linking external files?
Base64 Data URIs are ideal for tiny assets (under 2 KB) such as favicons, micro-icons, or critical inline SVGs, as they eliminate separate HTTP network handshakes. However, for larger images (> 10 KB), external links are preferable because Base64 increases file size by ~33% and cannot be cached independently by the browser.
Q:Are my sensitive inputs, keys, or files sent to any remote server?
No. 100% of encoding, decoding, file reading, and cryptographic parsing runs entirely within your browser using native JavaScript APIs (FileReader and TextEncoder/TextDecoder). No inputs, files, or tokens are ever uploaded to or stored on our servers.
What is Base64 Encoder/Decoder?
Handling binary data in text-based environments doesn't have to be a guessing game. Our completely client-side Base64 Encoder/Decoder is built specifically for modern web developers who need to process payloads instantly and securely. Because the encoding happens entirely within your browser's memory, you have a 100% privacy guarantee—your sensitive strings or files never hit our servers. Whether you are generating quick inline assets or debugging complex API responses, the integrated Smart Payload auto-detection will immediately identify the data format and format it beautifully.
A Real-World Developer Scenario: Eliminating HTTP Requests
Imagine a front-end developer working on a high-traffic e-commerce site. The homepage relies on dozens of tiny UI icons (like shopping carts and arrows). Instead of forcing the browser to make 20 separate HTTP requests to load these SVGs, the developer drags and drops the image files directly into our Data-URI builder. The tool instantly generates the inline <img> tags and CSS background snippets. Before copying the code, they check the Base64 Bloat Auditor, which confirms the string size is perfectly optimized and won't negatively impact the page's initial load time.
Developer Toolkit Breakdown
| Feature Set | Technical Benefit | Typical Use Case |
|---|---|---|
| URL-Safe Toggle (RFC 4648) | Swaps + and / for - and _. | Passing encoded data safely through URL query parameters without breaking routing. |
| Base64 Bloat Auditor | Calculates the exact +33.3% size penalty. | Deciding whether to inline an image or keep it as an external file. |
| JWT Inspector | Decodes headers and payloads in real-time. | Verifying user roles or expiration dates in a token during frontend authentication. |
History and Origin
In the early days of the internet, systems like email (SMTP) were strictly designed to handle 7-bit ASCII text. If you tried to send a binary file, like an image, the raw bytes would be misinterpreted as control characters, corrupting the message. Base64 was introduced as part of the MIME standard to solve this elegant problem: it translates unpredictable binary data into a safe, universally readable alphabet of 64 printable characters, ensuring files survive the journey across legacy networks.