Decode base64 on your Mac without a website

The blob in the header, and where it usually ends up

Base64 is everywhere in a developer’s day precisely because it is boring: a Basic auth header, a Kubernetes secret, a data URI, an SVG someone stuffed into CSS, the two segments of a JWT that matter. It exists to move bytes through a channel that only carries text. It hides nothing.

Which is the whole problem with the usual way of reading it. A base64 blob you bothered to copy is very often wrapping something you would not paste into a stranger’s form: a Kubernetes Secret value is base64 and nothing else, and Authorization: Basic … is a username and password with a reversible coat of paint. Typing “base64 decode” into a search box and pasting into the first result is a habit that treats an encoding as if it were an obfuscation.

The terminal way — pbpaste | base64 -d — is correct and private, and it still costs a window switch, a command you half-remember the flag for (-d or -D?), and a decode that scrolls past without telling you what it found.

Decoded on sight, and it keeps going

Copy the blob, press ⌘⇧V, read the decode. The panel names the alphabet it recognized — standard or the URL-safe variant, which is the fact that explains why a blob refuses to decode elsewhere — and how much text came out.

Paste decoded is the primary action on ↩, with the original still available under the paste variants and ⌘C. And when what comes out is itself a JSON document, Rakkun does not stop at one layer — the clip is treated as JSON and pretty-printed, which is the layer you actually wanted. (One honest limit: that unwrapping uses the strict decoder, so it only catches base64 written as a single unbroken line. A block wrapped at 64 columns, the way openssl base64 emits it, stays a base64 clip with its decode shown underneath.)

What happens when the decode is a secret

This is the case the privacy design exists for, and Rakkun’s answer is more conservative than you would guess. If the decoded text carries a credential — an API key, a token, a private key — the clip is not classified as base64 at all. It stays plain text, it gets no Paste decoded action, and the preview is masked: bullets, and nothing else. No surface in the app ever renders that decode in the clear.

The reasoning is that a convenience feature should not be the thing that puts a secret on screen. You can mark anything as a secret yourself with ⌘L, or unmark a false positive the same way, and hold ⌥ to reveal a masked value in the preview for as long as you hold it. Pin a masked clip and its real value moves into the macOS Keychain rather than the history file; unpinned, it lives only for the session.

Pasting still uses the real value. Masking is about what is on screen, not about crippling the clip.

Offline is enforced, not promised

Rakkun ships without a network entitlement. It is a sandboxed Mac App Store app, and the permission that would let it open a connection is absent from the binary — so macOS refuses one on the app’s behalf. That is the difference between a privacy policy and a property of the software: there is no account, no sync, no telemetry, and nothing that could upload a decoded secret even by mistake.

Content copied from a password manager never enters the history at all — concealed pasteboard types are skipped before they are read, so they are not masked, they are simply never there.