Base64 is not encryption, but the paste box still matters

Base64 turns bytes into printable ASCII. It is an encoding, not encryption - anyone can decode what you encode - but the practical problem is the same: a lot of web Base64 forms want your text on their server before they hand you the string back.

If the text is an API token, a signed URL, a config snippet or a support thread, that round trip through someone else's box is a choice you do not have to make.

Full disclosure: I work on OnePassApps. Its Text Studio has a Base64 tab that encodes and decodes inside the page you already have open. Here is what it actually does, checked in the live tab while writing this.

Open it here: the Text Studio

The panel

The Text Studio carries eight tool tabs on one page: Clean, Case, Duplicate lines, Sort lines, Find & replace, Diff, Markdown, Base64. Its own line at the top says it plainly: "Count, clean, compare and convert text locally. Your content stays in this browser tab."

The Base64 tab is laid out as three numbered steps.

01 Input text - one field, counter reading "0 / 2,000,000", placeholder "Paste or type text here. Nothing is uploaded.", and a live stats row underneath: Words, Characters, Sentences, Lines, UTF-8 bytes.

02 Mode - two settings, Encode UTF-8 and Decode Base64.

03 Result - the stage where the output lands. Its hint line reads "Base64 text shows on the stage, ready to copy, download or use as the new input." The page says "Nothing leaves this tab."

The action button is Encode or Decode, and once a run has finished it becomes "Encode again" or "Decode again". The stage offers three ways out: Copy, Download .txt, and "Use as input", which feeds the result straight into the next tool - so a decode can go on into a clean-up or a de-duplicate without a copy-paste in between.

The file picker accepts ".txt, .md, .csv and other text up to 8 MiB", and the page repeats "Processing stays in this browser."

Characters are not bytes, and the panel shows you both

The live stats row is the part that matters for Base64, because Base64 is defined over bytes.

I typed a string with two non-ASCII characters into the field:

OnePassApps base64 probe: café naïve

The counters moved to:

  • Words 5
  • Characters 36
  • Lines 1
  • UTF-8 bytes 38

Two characters are two bytes more than they are characters, because é and ï take two bytes each in UTF-8. The 38 bytes are what get encoded, not the 36 characters, and the panel tells you that before you press the button.

The output is deterministic, so you can check it

Base64 works in blocks of three bytes, padded with =. 38 bytes is twelve full blocks plus a remainder of two, so the encoded string is thirteen groups of four characters: 52 characters, with a single = at the end.

The result stage said exactly that - "52 characters · 1 line" and "Encoded in 0.1 s" - and the value it produced was:

T25lUGFzc0FwcHMgYmFzZTY0IHByb2JlOiBjYWbDqSBuYcOvdmU=

I checked that string outside the browser with Python's own base64 module over the same UTF-8 bytes, and it produced the identical 52-character string. When a panel prints a hash you want a second opinion; this is the same idea - the encoding is fully specified, so a second implementation should agree character for character.

The stage also labels where the work happened: "UTF-8 text encoded locally."

Decoding, and what happens when the input is wrong

Switching Mode to Decode Base64 relabels the field "Base64 input" and the action button to "Decode". The same string pasted back in came back out as the original text, with the stage reporting "Decoded in 0.1 s", "36 characters · 1 line", and "Base64 decoded as UTF-8 text."

Bad input is refused rather than mangled. I pasted text that was not valid Base64, and the stage answered "Invalid Base64: use standard Base64 characters and correct padding." followed by "Nothing was changed. Fix the problem and try again." Nothing half-decoded, no silent garbage characters, and the panel says the input was left alone.

Where the boundary is

The input field holds up to 2,000,000 characters and the file picker takes text files up to 8 MiB. Base64 also inflates what it encodes by roughly a third, so a decoded payload that fills the 2,000,000-character field was around 1.5 million characters of Base64 to begin with. And the output still has to reach whoever needs it eventually - the point is that it does not have to leave your device first, into an upload box you did not choose.

The plan

Standard is free right now: "100,000 credits every 30 days - No end date set - No card required", and the page is explicit about "No automatic paid subscription. Existing paid subscriptions keep their terms." The Base64 tab runs on your device, so the credits are not what it is for anyway.

If you want the wider picture of how the browser-local studios work, the guides cover it.

I work on OnePassApps - the Text Studio is one of nine apps on a single membership, and every one of these tools runs in the tab.