Developer / Local utility
Base64 encoder
Encode UTF-8 text as standard Base64 without sending it away.
About this Base64 encoder
Enter or paste text into the input field to encode it into standard Base64 or URL-safe Base64URL. The encoder converts Unicode strings to UTF-8 byte streams before encoding, preventing btoa Latin-1 character exceptions and outputting clean, properly padded Base64 in real time.
This tool encodes plain text, JSON payloads, and source code into standard Base64 representation directly in your browser. Standard browser btoa() functions crash with a Character Out of Range exception when given emojis, accented characters, or non-Latin text. Our implementation serializes text into standard UTF-8 byte arrays before translating into 6-bit ASCII representations, ensuring complete Unicode fidelity.
Step by step
- 1Type or paste input textEnter text, source code, or JSON into the text editor. Characters from all Unicode blocks are fully supported.
- 2Select encoding variantChoose standard RFC 4648 Base64 (using + and / with padding) or URL-safe Base64URL (using - and _ without padding).
- 3Review the encoded outputThe Base64 string updates in real time, with instant display of original byte size versus encoded output size.
- 4Copy or exportCopy the encoded string to your clipboard for use in configuration files, HTTP Authorization headers, or data URIs.
Overcoming the browser btoa() Unicode limitation
In JavaScript, window.btoa() accepts only Latin-1 binary strings (code points 0x00 to 0xFF). Any character outside this range (such as emojis or accented characters) throws an invalid character error. Our encoder utilizes TextEncoder to convert input strings to UTF-8 byte sequences first, guaranteeing error-free encoding of any global language.
Data expansion ratio and padding rules
Base64 encoding maps 3 bytes of binary data into 4 ASCII characters, resulting in an exact 33.3% size expansion. When the input byte count is not divisible by 3, one or two equals (=) characters are appended as padding to complete the final 4-character block.
Common use cases in modern web development
Base64 is indispensable across web engineering: constructing Basic Authentication headers, embedding inline SVG and font assets in CSS stylesheets via Data URIs, packaging binary cryptographic keys in PEM certificates, and transmitting JSON Web Token (JWT) claims across HTTP headers.
Binary buffer handling and line chunking options
When preparing Base64 data for email protocols or legacy systems, RFC 2045 recommends wrapping output lines at 76 characters, whereas OpenPGP and PEM certificates specify 64 characters. Our encoding engine processes data in continuous streams or structured blocks, providing predictable outputs for shell scripts, curl requests, and configuration files.
Zero upload security guarantee
Every response from this site is served with a Content Security Policy whose connect-src directive is set to none. That is not a promise in marketing copy; it is an instruction to your browser, and the browser is the one enforcing it. While this page is open it cannot open a connection to anywhere — not to this site, not to anyone else — so there is no path by which your document could be uploaded, not by a bug, not by a future change, not by a script that should not be here. e2e/egress-proof.spec.ts asserts the served header and then tries to send data out by every route a page has and requires each attempt to be refused, and it runs on every build.
The second half of the guarantee is that the code has nowhere to send anything from. lib/tools/local-source-policy.test.ts reads every source file under lib/tools, workers, components and app on every test run and fails the build if any of them contains fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon or a peer connection, or even a remote address written down in a comment. A tool here cannot acquire an upload by accident, because the file that would have to contain one cannot be committed.
Client-side processing limits
Computations run directly on your own device using WebAssembly, Web Workers, and modern browser APIs including Web Crypto and TextDecoder. There are no server queues, no background telemetry, and no temporary cloud files created. Large operations remain responsive by offloading heavy parsing and conversion tasks to dedicated worker threads, ensuring the browser UI never freezes during intensive document and data processing tasks.
Questions people ask
- Why does standard btoa() throw an exception on non-English text?
- The historical btoa specification only operates on 8-bit Latin-1 characters. Our encoder converts text to UTF-8 bytes first using TextEncoder, preventing crashes on Unicode characters.
- When should I choose Base64URL over standard Base64?
- Choose Base64URL when embedding tokens in URL query strings, URL paths, or JSON Web Tokens (JWTs), because plus (+) and slash (/) characters require URL escaping.
- Can I format the output as a data URI?
- Yes. Prepending "data:text/plain;charset=utf-8;base64," to the output creates a standard RFC 2397 Data URI ready for HTML and CSS embedding.
- Are encoded passwords or API credentials sent anywhere?
- Never. Encoding takes place entirely in local browser memory under strict CSP connect-src none isolation.
- What is the maximum payload size supported?
- The encoder processes strings up to 2,000,000 characters without memory thrashing or UI freezing.