Why Send to Kindle is broken (and what we rebuilt)

Amazon has shipped Send to Kindle by email since 2011. It works well for one thing: emailing PDFs and DOCs you already have on your machine. For sending random web articles, it falls apart in three specific ways. We rebuilt the whole pipeline.

Failure 1: paywalls on publications you pay for

Most send-to-Kindle services (including Amazon itself, Push to Kindle, and others) fetch the URL from their server. You paste the link, their server hits the URL, and processes whatever HTML it gets back.

The problem is that editorial sites depend on paywalls today. You are logged into the NYT on your browser, but the Send to Kindle server is not. When it fetches, it gets the public page: "Subscribe to read this article." The article never reaches the Kindle.

The fix is capturing the content inside the user's browser session. Folio runs as a browser extension, PWA, or bookmarklet. When you click "send," the capture happens in your browser, with your cookies, your session. The paywall is irrelevant because you are already authenticated.

Important detail: we never send your credentials or cookies to our servers. Only the processed HTML of the page you already have access to.

Failure 2: throwaway typography

Send to Kindle accepts HTML. Amazon converts it to MOBI (legacy format) or AZW3. The conversion is literal: the HTML you send is rendered almost as-is. Result: sidebars, ads, navigation, all show up on the e-reader.

Even with pre-cleanup, Amazon uses default fonts (Bookerly), default margins, default spacing. You do not control these. For long articles read over hours, the difference between editorial typography and generic typography is accumulated fatigue.

We built Folio around per-user EPUB generation. Four serif families available (Bookerly clone, Newsreader, EB Garamond, Source Serif), four sizes, editorial margins capped at 75 characters per line. Every EPUB ships with first-line paragraph indentation, controlled section spacing, and preserved footnotes.

Failure 3: unmonitored delivery

Send to Kindle uses regular email. You add the sender address to Amazon's whitelist (manual step). Email passes through filters, SPF, DKIM, and sometimes a processing queue that takes hours.

Frequent Send to Kindle users know the pattern: sometimes the article lands in 30 seconds, sometimes in 2 hours, sometimes never. No feedback on failures.

At Folio, we use Resend for delivery, with DKIM + SPF + DMARC aligned for folio.today. Internal tracking shows the status of every send (queued, processing, sent, failed) in real time on the dashboard. On permanent failure, you get a direct notification.

What we rebuilt

Summary of the three structural choices:

• Capture in the user's browser: paywalls preserved.
• Custom editorial EPUB: typography controlled per user.
• Monitored delivery: visible status, automatic retry.

The engineering underneath is more complex than the result makes it look. HTML sanitization with DOMPurify, extraction with Readability, EPUB generation with epub-gen-memory, async pipeline with Inngest, idempotency. The complexity is worth it because the result is radically different.