Decode Base64 locally without uploading a token
A practical Base64 decode flow for JWT segments, API payloads and UTF-8 strings that should stay in the browser.
The Slack thread has one log line: eyJ1c2VySWQiOiI0MiIsInNjb3BlIjoiYWRtaW4ifQ==. It looks like Base64. The fast move is to paste it into the first converter from search, but the string may contain a user id, a scope, a webhook payload fragment or a temporary token from a dev environment.
Open Base64 encode/decode, switch to Decode or click Auto. txtify strips whitespace, checks the A-Z, a-z, 0-9, +, /, = alphabet and tries to rebuild a UTF-8 string in the current tab. The field contents do not leave the browser. Privacy copy is easy to write; the Network tab is harder to fake.
Why I do not paste this into the first decoder
The broad "base64 decode online" result page is full of older utility sites: base64decode.org, base64encode.org, Base64 Guru and CyberChef. They are useful, but they also try to cover every edge at once: character sets, 100 MB files, MIME line wrapping at 76 characters, URL-safe mode and separate pages for images, PDFs and Basic Auth.
When you need a full workbench, fine. Most work messages are smaller: "what is inside this string?" For that job, extra switches add noise. File upload next to the text field also changes the habit. base64decode.org has a browser live mode, but its file flow is explicitly an upload flow with temporary server storage. I would not train myself to paste tokens there just because the site promises cleanup after 15 minutes.
JWT and UTF-8 are the two traps
Base64 is not encryption. If the decoded value is JSON, you did not crack a token; you only read an open payload. A JWT usually has three dot-separated parts: header, payload, signature. The first two often use Base64URL, where - and _ replace + and /, and = padding is often omitted. A strict regular Base64 decoder can reject that input. That is expected.
Unicode is the other trap. Old atob() gives you bytes shaped like a string, and Cyrillic or emoji can break if the next step treats those bytes as Latin-1. txtify encodes text through TextEncoder and decodes through TextDecoder('utf-8', { fatal: true }). So Привет round-trips as text, while broken bytes produce a visible error instead of quiet garbage.
For files, use a file-specific tool. This txtify page is about short text fragments: JSON payloads, test tokens, config snippets and webhook body pieces. Local decoding pays for itself there: it is faster, calmer and it does not turn a copied token into somebody else's form submission.
Questions
Does txtify send Base64 input to a server?
No. String encoding and decoding run in the browser, without an upload request carrying the field contents.
Why can valid Base64 fail as text?
The current tool is built for UTF-8 strings. If the decoded bytes are an image, archive or another binary file, the Base64 may be valid but it will not become readable text.