Base64 Tool

Base64 is a binary-to-text encoding scheme defined in RFC 4648 that converts any binary data into a string of 64 printable ASCII characters: uppercase A-Z (26), lowercase a-z (26), digits 0-9 (10), plus (+), and slash (/), with equals (=) used for padding. Every 3 bytes of input data are encoded into 4 Base64 characters. This encoding ensures that binary data can be safely transmitted through text-based systems like email (MIME), URLs, JSON, XML, and HTTP headers without corruption from character encoding issues.

Base64 is used extensively in web development for several purposes: (1) Data URIs — embedding small images, fonts, or SVGs directly in CSS or HTML as data:image/png;base64,... to reduce HTTP requests. (2) API authentication — HTTP Basic Auth encodes username:password in Base64. (3) JWT tokens — the header and payload sections of JSON Web Tokens are Base64URL-encoded. (4) Email attachments — MIME encoding uses Base64 to embed binary files in text-based email protocols. (5) Kubernetes secrets — config values are stored as Base64-encoded strings in YAML manifests.

Base64 encoding increases data size by approximately 33%. Every 3 bytes of input become 4 bytes of Base64 output (a 4:3 ratio). For example, a 3 KB file becomes approximately 4 KB when Base64-encoded. Additionally, padding characters (=) may add 1-2 bytes at the end. This size overhead is displayed by this tool, showing both input and output byte sizes so you can see the exact expansion for your specific data.

No, Base64 is not encryption and provides no security whatsoever. Base64 is a reversible encoding scheme — anyone can decode a Base64 string back to its original data without any key or password. It is purely a format conversion for making binary data text-safe. If you need to protect sensitive data, you should use actual encryption (AES, RSA, etc.) and then optionally Base64-encode the encrypted result for text-safe transmission.

Standard Base64 uses + and / as the 63rd and 64th characters, and = for padding. Base64URL (defined in RFC 4648 Section 5) replaces + with - and / with _ to make the output safe for use in URLs and filenames, where + and / have special meanings. Base64URL also typically omits the = padding. JWT tokens use Base64URL encoding for their header and payload segments. This tool uses standard Base64 encoding, which is appropriate for most use cases including data URIs, MIME encoding, and API payloads.

Use Base64 when you need to encode arbitrary binary data (images, files, encrypted bytes) into a text string, or when embedding data in contexts like JSON values, XML content, or email bodies. Use URL encoding (percent-encoding) when you need to include special characters in URLs, query parameters, or form data — it only encodes the specific characters that are unsafe in URLs. Base64 is a full data transformation (every byte is re-encoded), while URL encoding only modifies characters that need escaping.

Standard Base64 (via btoa/atob in JavaScript) only handles Latin-1 characters directly. This tool uses a UTF-8 encoding layer (encodeURIComponent/decodeURIComponent) before Base64 encoding, which correctly handles all Unicode characters including Korean, Chinese, Japanese, Arabic, emoji, and any other UTF-8 text. Without this UTF-8 preprocessing, attempting to Base64-encode non-Latin characters would throw a "character out of range" error.

If decoding fails, check for common issues: (1) Ensure the string contains only valid Base64 characters (A-Z, a-z, 0-9, +, /, =). (2) Check for line breaks or whitespace that may have been inserted during copy-paste — remove them before decoding. (3) Verify the padding is correct (the string length should be divisible by 4, with = padding as needed). (4) If the string uses - and _ instead of + and /, it may be Base64URL-encoded — replace those characters before using standard Base64 decoding. This tool provides specific error messages to help diagnose decoding failures.