Why we ship our sales tax calculator as an iframe embed (and not an npm package)

#webdev #opensource #api #html

We open-sourced ReceiptEdit's 2026 US sales tax dataset and shipped it three ways: a public REST API at receiptedit.com/api/sales-tax, downloadable CSV/JSON on GitHub, and an iframe-embeddable calculator widget.

Here is why the iframe embed matters as much as the API.

Different consumer, same data

API: a developer building a tool. They handle rendering, error states, styling.
Iframe: a content marketer, blogger, or founder who wants a live calculator on their page in 10 seconds. Zero JS to install. Zero styling to fight.

Same source dataset, two audiences.

The one-liner

<iframe
  src="https://receiptedit.com/api/embed/sales-tax/california"
  width="380" height="540"
  style="border:0;max-width:100%"
  loading="lazy">
</iframe>

Swap california for any state slug. That is the whole integration.

Why not an npm package?

Blogger on Medium/WordPress/Substack cannot npm install.
Every dependency bump is a break window I own.
CSP-strict sites reject third-party JS wholesale.

An iframe hard-isolates my styles from theirs (no cascade fights, no CSP violations, no JS runtime clashes). Same-origin cookies stay separate. My update pushes to their page automatically with zero action on their side.

The tradeoff

Iframes cannot share the parent page's design system. You get my calculator style, not your brand style. For most publishers that is a fine tradeoff for the install-simplicity.

Who uses it

Small business bloggers, freelancer expense guides, and tax-prep articles. If you write about state taxes, embed the widget so your reader gets the number without leaving your page.