Why I Built a PGP Encryption Layer for Gmail (And Open-Sourced the Chrome Extension)

Why I Built a PGP Encryption Layer for Gmail (And Open-Sourced the Chrome Extension)
I sent a contract over Gmail last year. Nothing fancy — just a freelance agreement with a client's banking details for direct deposit. Hit send, moved on with my day.

Three weeks later, that client got a phishing email referencing exact dollar amounts from our agreement. Someone had scraped it. Maybe from a compromised inbox, maybe from a server breach, maybe from something else entirely. The point is: the email sat on Google's servers in plaintext the entire time.

That's the moment I stopped assuming Gmail "encryption" meant what I thought it meant.

What Gmail Actually Encrypts (And What It Doesn't)
Here's the thing most developers don't realize until they dig into it. Gmail uses TLS — Transport Layer Security. Your email is encrypted while it's moving between servers. The little padlock icon in your browser? That's TLS doing its job.

But once your email lands on Google's servers, it's stored in a format Google can read. Their systems scan it for spam filtering. Smart Reply reads it to suggest responses. Ads used to be targeted based on email content (Google says they stopped, but the infrastructure to do it never went away).

TLS protects your email from a man-in-the-middle attack during transit. It does absolutely nothing if Google's servers get breached, if a government subpoena demands your data, or if a rogue employee decides to peek.

TLS encryption:
  You  ──[encrypted]──>  Google Server  ──[encrypted]──>  Recipient
                              │
                         [plaintext]
                         Google can read it here.

End-to-end encryption (PGP):
  You  ──[encrypted]──>  Google Server  ──[encrypted]──>  Recipient
                              │
                         [still encrypted]
                         Nobody reads it. Not even Google.

That gap between "encrypted in transit" and "actually private" is what kept bugging me.

So I Built GmailKrypt
GmailKrypt is a Chrome extension that bolts PGP encryption directly onto Gmail's interface. No separate app. No copy-pasting into a terminal. You compose your email like you normally would, click encrypt, and send.

The whole thing runs on OpenPGP.js — the same standard that's been protecting communications since Phil Zimmermann released PGP back in 1991. Except now you don't need to touch a command line to use it.

How It Actually Works in Practice
You install the extension. It generates a key pair for you — a public key and a private key. Your private key stays in Chrome's local storage. It never hits a server. Not mine. Not Google's. Nobody's.

When you want to send an encrypted email:

Compose your email in Gmail like normal
Click the GmailKrypt encrypt button in the toolbar
The extension encrypts the message body using the recipient's public key
Gmail sends what looks like a block of gibberish
What your recipient sees before decryption:

-----BEGIN PGP MESSAGE-----

hQEMA7Vj8+t5rZ7aAQf+N2M7j8K2vF9xD3nE1yP4mR6sQ
8tA5bC7dF0gH3iK6lN9oR2sU5vX8yB1cE4fG7hJ0kL3mO
6pS9tW2xA5zC8dF1gI4jL7nQ0rU3vY6aD9eH2iK5lN8oR1
=x7Fp
-----END PGP MESSAGE-----

If the recipient has GmailKrypt installed, the extension detects the PGP block and decrypts it automatically. If they use any other PGP tool — Thunderbird, GPG Suite, Kleopatra — it works just the same. That's the beauty of open standards.

The Architecture (For the Nerds)
I know this is dev.to, so let's get into the guts of it.

Zero-knowledge design. The extension uses chrome.storage.local for private keys. They're sandboxed by Chrome's extension security model. The API server I run at api.gmailkrypt.com handles licensing and Stripe subscriptions — it never touches keys, never sees message content, never stores anything it shouldn't.

Content script injection. GmailKrypt injects into Gmail's DOM to add the encrypt/decrypt toolbar. It listens for compose window events and intercepts the message body before send. All the crypto happens client-side through OpenPGP.js.

Key exchange. This was the UX challenge. PGP has always been powerful but painful to set up. GmailKrypt lets you attach your public key to any email with a single button click. The recipient imports it, sends theirs back, and you're set. First exchange takes maybe 30 seconds.

// Simplified flow
const { privateKey, publicKey } = await openpgp.generateKey({
  type: 'ecc',
  curve: 'curve25519',
  userIDs: [{ email: '[e-mail]' }]
});

// Encrypt
const encrypted = await openpgp.encrypt({
  message: await openpgp.createMessage({ text: emailBody }),
  encryptionKeys: recipientPublicKey,
  signingKeys: myPrivateKey  // also signs it
});

Digital signatures come free with PGP. Every encrypted email is also signed, so the recipient can verify it actually came from you and wasn't tampered with in transit. Authentication, integrity, and non-repudiation — all in one operation.

Who Is This Actually For?
I built this scratching my own itch, but it turns out a lot of people have the same itch.

Freelancers and contractors sending invoices with bank details over email. Lawyers who have attorney-client privilege to protect but keep using Gmail because their firm is on Google Workspace. Journalists communicating with sources — Snowden used PGP with Glenn Greenwald for a reason. Healthcare folks who technically violate HIPAA every time they email patient info through standard Gmail. Developers who want to practice what they preach about security.

Or honestly? Anyone who's ever sent a password, a credit card number, or a social security number over email and felt that little twinge of "I probably shouldn't have done that."

The Google Workspace Elephant in the Room
Google does offer something called S/MIME encryption for Workspace Enterprise customers. It costs significantly more than standard Workspace, requires your IT admin to manage certificates, and only works between users whose organizations have both set up S/MIME correctly.

For the other 1.8 billion Gmail users? Nothing.

That's not an oversight. Google's business model fundamentally conflicts with end-to-end encryption. If they can't read your emails, they can't power Smart Compose, can't filter spam as effectively, can't build the profile that drives their ad ecosystem. I'm not saying that's evil — it's just the reality of a free product.

GmailKrypt sidesteps all of that. It works with free Gmail, Google Workspace, any plan. You're adding encryption on top of Gmail, not asking Google to provide it.

Free Tier, Pro Tier, No BS
The extension is free to use — you get 5 encryptions per day, which covers most people's needs. If you're sending encrypted emails all day (lawyers, journalists, security teams), the Pro plan is $4.99/month for unlimited everything.

I thought long and hard about pricing. I wanted it accessible enough that a student or activist could use it without paying, but sustainable enough that I can keep maintaining it. Five free encryptions felt like the right balance.

Try It, Break It, Tell Me What's Wrong
You can grab GmailKrypt from the Chrome Web Store or check out the landing page at gmailkrypt.com.

If you're the type who reads source code before installing extensions (and you should be), the extension runs entirely client-side for all crypto operations. The only network calls are to the license API for Pro features.

I'm genuinely curious what this community thinks. Is PGP email encryption still relevant in 2026? Are there UX improvements that would make you actually use this? Did I miss something obvious in the architecture?

Drop a comment. I read all of them.