Encode UTF-8 text with RFC 4648 standard or URL-safe Base64 and an explicit padding policy, with strict errors and no encryption claim.
A quick decision brief for this specific tool
Input plus Encoding
Base64
A dedicated interactive panel for this data format or operation
Choose your path
Encode exact Unicode text as UTF-8 using RFC 4648 standard or URL-safe Base64, with explicit padding policy and a visible boundary that encoding is not encryption or secret protection.
Choose the exact standard/URL-safe alphabet and padding policy required by the receiving protocol.
Keep encoder mode explicit, select alphabet/padding, enter Unicode text, compare bytes/output and save the stated mode.
The receiver decodes the same UTF-8 text and the Project record captures the variant.
Stop Base64 from being recommended as confidentiality, hashing, integrity or authentication.
Read the boundary warning, avoid entering secrets, and route protection requirements to the real protocol/security design.
No reversible encoded string is accepted as protected data.
Verify CJK, accents, emoji, malformed UTF-16, strict UTF-8 decode and named controls.
Run round trips and invalid inputs, inspect errors, use keyboard controls and save only bounded output.
Valid text round-trips exactly while malformed surrogates and non-UTF-8 bytes fail explicitly.
Outputs and checklists are planning aids. Review the linked current authorities and the records, terms, instructions, and requirements that apply to your exact situation before a consequential decision.
This tool is part of these guided projects. Each project provides step-by-step instructions with checklists and all the tools you need in one place.
Tools you might need next
Strictly decode standard or URL-safe Base64 into UTF-8 text, with explicit malformed-input errors and an untrusted-output security boundary.
Percent-encode one Unicode URI component with encodeURIComponent semantics, explicit context limits, and malformed UTF-16 rejection.
Parse a JWT locally to inspect its segments and claims. Decoding alone does not verify signature, issuer, audience, expiry, authorization, or trust.
Input bytes are grouped into 24-bit chunks, split into four 6-bit values, and mapped to ASCII characters A–Z, a–z, 0–9, +, and /. Padding with = completes partial groups.
Output length ≈ ⌈(input bytes × 4) ÷ 3⌉Text is first encoded to UTF-8 bytes before Base64 conversion, ensuring emoji, CJK characters, and accented letters encode correctly — not limited to ASCII input.
Standard Base64 uses + and / which require URL encoding in query strings. URL-safe variants replace + with - and / with _, and often omit padding — common in JWTs and web tokens.
Updated: July 2026
Encode the literal training value demo-client:sample only to verify a receiving system's documented Base64 alphabet and padding convention; never treat the output as protected.
→ ZGVtby1jbGllbnQ6c2FtcGxl
Encode a small SVG icon as a Base64 data URL for embedding in HTML or CSS.
→ Raw Base64 text; add a data-URL media type only when the consuming specification requires it
A developer Base64-encodes a small JSON filter object to pass safely in a URL query string.
→ eyJzdGF0dXMiOiJhY3RpdmUiLCJsaW1pdCI6MTB9
Base64 is encoding, not encryption. Anyone can decode it instantly. Never use Base64 alone to protect passwords, API keys, or sensitive data.
Double-encoding inflates size and breaks decoding. Encode raw text or binary once. If the input looks like random letters ending in =, decode first before re-encoding.
Convert plain text to Base64 encoding for APIs, data URLs, and safe transport of binary data over text-only channels. Supports Unicode characters and runs entirely in your browser for privacy.