At a glance
| Decision factor | Satori | ogshot |
|---|---|---|
| Rendering engine | Custom HTML/CSS-to-SVG layout | Real Chromium |
| Input model | Pure, stateless JSX subset | URL or complete HTML document |
| CSS | Documented subset | Whatever the bundled browser supports |
| Scripts & external styles | Not accepted in the input | Supported under network policy |
| Animation output | Static SVG pipeline | GIF, WebP, or MP4 recording |
| Operations | You run the rendering pipeline | Hosted browser pool, API, quota, and cache |
| Starting cost | Open-source library | 100 hosted renders/month free |
Disclosure: ogshot publishes this page. Satori facts come from the official Satori repository; the comparison was reviewed July 9, 2026. Verify current behavior before making a production decision.
Where Satori is the better choice
Satori is open source and returns SVG from a pure, stateless JSX tree. It is a strong fit for teams that want the renderer inside their own application, already use React-like components, can provide font data directly, and can express the entire card with the documented subset. The lack of a browser process reduces operational weight and can make simple, deterministic cards fast.
It is also the natural option when SVG is the desired intermediate format or when introducing a hosted dependency is unacceptable. If your design is a controlled flex layout with text, gradients, and known assets, the subset may not feel limiting at all.
Where the subset becomes the product constraint
Satori's own documentation says it supports a limited subset of HTML and CSS, does not accept style, link, or script elements, uses its own layout engine, and does not guarantee an exact match with browser-rendered HTML. Advanced typography support and some language behavior also differ from a browser.
Those are reasonable tradeoffs for a lightweight SVG engine, but they matter when an OG card shares components with a website, loads existing styles or fonts, relies on grid and newer CSS, or needs JavaScript to draw a chart. A layout that works in Chrome can require a separate Satori-specific implementation.
What real Chromium changes
ogshot sends the HTML to Chromium itself. The card can use standard style sheets, web fonts, CSS grid and flexbox, SVG, canvas, JavaScript, and the same layout engine used to view the web. A URL can be captured directly, or a complete HTML document can be posted without deploying it first.
The browser also makes motion possible. With animate=true, ogshot records CSS and JavaScript animation and returns GIF, WebP, or MP4. Discord and Slack can play appropriate animated image unfurls, while static platforms can receive a settled image authored through prefers-reduced-motion.
The tradeoff moves from design to operations
Chromium consumes more memory, starts more slowly, and creates a network security boundary. ogshot handles that with a warm concurrency-limited browser pool, deterministic caching, public-address enforcement on every browser request, service-worker blocking, timeouts, and machine-readable failures. That hosted layer is the service you pay for.
If you already operate reliable browser infrastructure, ogshot may be unnecessary. If you do not want browser crashes, memory behavior, queueing, caching, video transcoding, and SSRF controls inside your application, the hosted API removes that work.
A practical migration test
Take the hardest card in your current Satori implementation—not the simplest—and paste the equivalent HTML into the ogshot playground. Compare fonts, line wrapping, gradients, images, and international text. Then test one normal card and measure the operational difference. The right renderer is the one that reduces total maintenance for your actual designs.
For a framework-specific setup, use the Next.js guide or Astro guide. For a hosted-service comparison, see ogshot and ScreenshotOne.