age — pronounced like the Italian "agghi" — was released in 2019 by Filippo Valsorda, then leading the Go cryptography team. The original Go implementation is now a stable, audited piece of software. A Rust port called rage exists for environments that need a native binary without a Go runtime. Both implement the same on-the-wire format, specified in a short, deliberately minimal document.
age is not trying to replace every feature of GPG. It does one thing: encrypt a file to one or more recipients. There is no keyring, no web of trust, no signing, no key servers, no PGP messages embedded in email. If you need those things, GPG remains the right tool. If you don't, age is a smaller surface to learn, audit, and trust.
What GPG Carries
GPG (the GNU implementation of OpenPGP, RFC 4880 and successors) is a complete cryptographic suite. It does file encryption, message encryption, code signing, package signing, identity management, and a directory service for public keys. Each of these is a different feature with different trade-offs, and each has accumulated configuration knobs over decades.
That breadth is a virtue when you need it and a liability when you don't. A user who wants to encrypt one file to one recipient is making decisions about cipher suites, key types, key servers, expiration dates, and trust signatures whether they realize it or not. GPG's defaults have improved over time, but the surface area exposed to the user remains large. The Wikipedia table of GPG command-line flags fills several screens.
And then there's the user experience. Quoting cryptographer Moxie Marlinspike from a widely-shared 2015 essay, "GPG and Me":
"I think of GPG as a glorious experiment that has run its course... The world today is starkly different than the one twenty years ago, but GPG hasn't really changed."
What age Does Instead
age strips file encryption down to one job. The format supports two kinds of recipients:
- X25519 keys — short, base64 public keys; the holder of the corresponding private key can decrypt.
- Passphrase recipients — a passphrase derived through scrypt; anyone who knows the passphrase can decrypt.
That's the whole identity model. There is no keyring file. There is no central directory. You manage your keys however you like — in a password manager, on a hardware token, in a plain file — and you give age either a key file or a recipient string.
The recipient string for an X25519 key looks like this:
age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p
It's a Bech32-encoded public key — short enough to paste in a Slack message, long enough to be secure. There is no email address, no name, no expiration. The recipient identifier is the cryptographic identity.
The Format Itself
age files have a small, readable header followed by an authenticated stream. The header lists each recipient with the data they need to derive the file's symmetric key. Under the hood, age uses ChaCha20-Poly1305 for the encrypted payload — a modern AEAD construction with no historical baggage. Key derivation uses HKDF, also modern and well-audited.
The specification is short enough to read in one sitting. Compare with the OpenPGP specifications, which run to hundreds of pages and define multiple incompatible packet formats accumulated over decades.
SSH Keys as age Recipients
The single best ergonomic decision in age was supporting SSH keys directly. If your colleague has an Ed25519 or RSA SSH key on GitHub, you can encrypt a file to them with:
age -R <(curl https://github.com/username.keys) -o secret.age secret.txt
No new keys to generate, no new tool to install on the recipient side, no key exchange to negotiate. The SSH key they already have is the identity. This single feature has done more for adoption than any other.
Honest Comparison
| Property | GPG | age |
|---|---|---|
| File encryption | ✓ | ✓ |
| Email encryption (inline / PGP/MIME) | ✓ | ✗ |
| Digital signatures | ✓ | ✗ |
| Keyring management | Built in | You handle it |
| Web of trust | ✓ (largely abandoned in practice) | ✗ |
| Hardware token (YubiKey) support | ✓ | Via plugins (PIV, YubiKey) |
| Specification length | Many hundreds of pages | A few dozen pages |
| Default cipher suite | Configurable, several legacy options | One AEAD construction, no options |
| Best fit | Email, signing, package distribution | File encryption, secrets in repos, backups |
Where age Shines
age has become the default tool for several specific workflows:
Encrypted secrets in git
The Mozilla project SOPS and the related tool sops-nix use age as one of their backend formats. Encrypting a YAML file of secrets per-developer-public-key, committing it to git, and having each developer decrypt with their own private key is a clean model that doesn't need any infrastructure.
Encrypted backups
Tools like restic have their own encryption, but for one-off encrypted backups — a tarball you want to drop on cloud storage — age plus standard Unix piping is hard to beat. The decryption path is the same age binary, with no version compatibility worries.
Sharing files between developers
The SSH-key-as-recipient feature makes age the natural tool for "send Alice this file, encrypted." If Alice has a GitHub account with a public key, no setup is needed. age is also used by the popular passage password manager — an age-native fork of the classic Unix pass.
What age Won't Do
age has no signing primitive. If you need to prove a file was produced by a specific holder of a specific key, age won't help you. The original argument was that detached signatures are a different cryptographic problem, and combining them awkwardly with encryption was one of OpenPGP's mistakes. The current answer is to use Sigstore, minisign, or signify for signatures.
age has no key revocation. If your age private key leaks, the only remedy is to generate a new key and re-encrypt anything you still want accessible. For static archives, this is fine. For long-running encrypted stores, the burden is on you to plan rotation.
age has no email integration. You will not be using age as a drop-in replacement for OpenPGP/MIME email. If you want encrypted email, use a service or protocol built for it — and if you need to send a file securely as part of a workflow, encrypt the file with age and send the result.
When GPG Still Wins
GPG remains the right answer for several specific use cases:
- Signing software releases and Linux distribution packages
- Email encryption when both parties already use it
- Hardware-backed signing with full OpenPGP smartcard support
- Legacy compatibility with existing PGP keyrings
For everything else — and that is most everyday file encryption — age is a smaller, sharper tool with shorter manuals and fewer footguns. The point isn't that GPG is bad. The point is that doing one job well, with a spec you can read in an afternoon, turns out to be enough for most of what users actually need.