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.
A support 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. devdeck 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. They are useful, but they also try to cover every edge at once: character sets, large 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. I would not train myself to paste tokens into a page just because the site promises cleanup later.
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. devdeck 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 devdeck 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 devdeck 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 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.