Catch wrong emails. Before release.
Check that your receipts, invitations and password resets contain the right totals, roles, expiry text and links across languages and conditional branches. Find the failing element, repair your template, and run the same requirements in CI with saved project rules.
No signup for browser previews. Shared rules and CI gates require a paid plan; check current checkout availability before planning a paid rollout.
Build-quality loop
Three layers before your email ships
Define what each variation must contain, keep required branches covered, and review the same evidence in the browser and your build pipeline.
What is a CSS Inliner?
A CSS inliner is a tool that takes CSS from <style> tags and moves it directly into each HTML element's style="" attribute. Inline attributes are supported far more consistently across email clients than <style> blocks — which many clients ignore or apply inconsistently — so inlining is the most reliable way to keep your layout intact wherever it's read.
Inliner API automates that step, then keeps checking quality on top of it: static preflight on your source, project baselines for regression, and a CI gate that fails only on new issues.
Why pay for an email build pipeline?
Less repeated manual checking
Write the expected synthetic content once and rerun the same checks after changing your template.
Find the responsible branch
The repair checklist groups failures by rule and names the affected scenarios and HTML selectors.
Keep expectations consistent
Saved project rules apply to API and CI runs. A caller cannot waive a mandatory content failure with a lint threshold.
Start with an actual workflow
Try receipt, invitation and password-reset examples without an account, then edit the rules for your own synthetic fixtures.
Evidence you can review
Reports include rule snapshots and check results. Findings omit matched text; snapshots retain configured expected text. Use synthetic fixtures and review exports before sharing.
Fit your existing build
Use rendered HTML from React Email, MJML or another renderer. Download starter code or connect the Node SDK and GitHub Action. Integrations remain pre-release.
Test the release checks yourself
Start with synthetic examples. Previews do not save a server release; a browser copy is saved only when you choose it. Projects provide shared rules and release history.
Business content
Check expected text, required or forbidden sections, approved links and unfilled template tags.
Try requirements →Template scenarios
Try a receipt with the wrong euro total, an invitation with the wrong role, or an incorrect reset expiry.
Try scenario matrix →Client compatibility
Inspect recorded support and source dates for selected email clients and CSS features.
Inspect compatibility →How do you test a transactional email?
Render synthetic examples from your source template, define the expected content for each branch, and check every required variation. Keep visual inbox review and delivery testing as separate steps.
Read the React Email and MJML testing guide →Copy-paste ready
Preview now. Add the API when ready.
The Playground needs no key. For API calls, create a free key in your Dashboard.
The Node SDK and GitHub Action are pre-release — the exact contract is documented in the Docs. The curl example needs your own API key.
curl -X POST https://inlinerapi.netlify.app/api/inline \
-H "Authorization: Bearer sk_live_xxx" \
-d '{"html":"<style>.red{color:red}</style><p class=red>Hello</p>"}'
# → <p style="color:red">Hello</p>