UTF-8 aware
Unicode text is converted from its UTF-8 byte representation.
Start typing to search 227 tools.
Encode UTF-8 text to standard Base64 online with optional 64- or 76-character line wrapping and canonical padding.
Base64 Encoder converts UTF-8 text into standard Base64. It is useful for API examples, configuration values, test fixtures, email/MIME workflows and other systems that need binary-safe text transport.
The encoder works from the UTF-8 bytes of the supplied text. You can keep canonical = padding, remove it when a destination expects unpadded Base64, or wrap long output at 64 or 76 characters per line.
Base64 is reversible encoding, not encryption. Anyone who has the encoded value can decode it.
= for canonical Base64 unless the destination explicitly omits it.Focused controls, predictable output, and a workflow designed around this exact transformation.
Unicode text is converted from its UTF-8 byte representation.
Produce single-line output or 64/76-character wrapped Base64.
Keep canonical padding or omit it when required by a destination.
Encoded output remains separate from the source for easy verification.
Practical details about input, output, privacy, limits, and the best way to use this tool.
Base64 represents binary bytes using a 64-character ASCII alphabet. It is designed for transport and storage, not secrecy.
No. Base64 is reversible and provides no confidentiality.
Base64 operates on bytes. Trexmi encodes the UTF-8 bytes of your text, which is the common web and API convention.
One or two trailing = characters complete the final 4-character Base64 group. Some protocols omit padding, while canonical Base64 keeps it.
76-character wrapping is commonly associated with MIME transport. Many APIs instead expect one uninterrupted line.
Yes. Paste it into the Base64 Decoder and confirm that it returns the original text.
Understand Base64 encoding, decoding, Base64URL, UTF-8 input, padding, data URLs, and frequent integration mistakes.
Canonical padding is retained for this UTF-8 input.
Hello, Trexmi!
SGVsbG8sIFRyZXhtaSE=
Unicode characters are encoded from their UTF-8 bytes.
Привіт, Trexmi!
0J/RgNC40LLRltGCLCBUcmV4bWkh
Removing padding changes the transport representation, not the decoded bytes.
Hello
With padding: SGVsbG8= Without padding: SGVsbG8
Input: Hello, Trexmi!
Padding: enabled
Output: SGVsbG8sIFRyZXhtaSE=
Input: Привіт, Trexmi!
Padding: enabled
Output: 0J/RgNC40LLRltGCLCBUcmV4bWkh
Input: {"active":true}
Output: eyJhY3RpdmUiOnRydWV9
Input: Hello
With padding: SGVsbG8=
Without padding: SGVsbG8
Single-line output is typical for APIs and configuration. A 76-character line length is common in MIME contexts, while 64-character wrapping appears in some PEM-style and legacy workflows. Wrapping changes presentation only; removing line breaks produces the same Base64 character sequence.
Canonical Base64 uses one or two trailing = characters when required by the final byte group. Omit padding only when the receiving format explicitly allows it.
Standard Base64 uses + and /. Base64URL substitutes - and _ and commonly removes padding. Encoding with this tool does not automatically produce Base64URL.
If standard Base64 must travel as a URL query value, percent-encode it rather than replacing characters by hand. Use URL Encoder for that separate transport step.
Verify a round trip with Base64 Decoder, encode a query component with URL Encoder, or prepare JSON source with JSON Formatter.
Base64 is specified in RFC 4648.