Satori renders JSX to an SVG string with its own layout engine, and skips the browser entirely

One call returns an SVG string, with no browser in the path

Calling satori() takes a JSX element and an options object, and gives back an SVG string rather than a file on disk. The README renders hello, world at 600 by 400 with a color, and the result looks like '<svg ...><path d="..." fill="black"></path></svg>', with the text turned into a path. No browser, no DOM, and no screenshot step sits in that path. Layout calculation, font handling, and typography all happen inside the library, which is the reason it can run on a server. The call has two required shapes: the element itself, and an options object carrying width, height, and a fonts array. The package name comes from package.json (satori, published as MPL-2.0) and the quickest first look is the playground at og-playground.vercel.app; for turning the SVG into PNG Open Graph cards the README redirects to Vercel's Open Graph Image Generation docs.

// api.jsx
import satori from 'satori'

const svg = await satori(
  <div style={{ color: 'black' }}>hello, world</div>,
  {
    width: 600,
    height: 400,
    fonts: [
      {
        name: 'Roboto',
        // Use `fs` (Node.js only) or `fetch` to read the font as Buffer/ArrayBuffer and provide `data` here.
        data: robotoArrayBuffer,
        weight: 400,
        style: 'normal',
      },
    ],
  },
)

Yoga does the layout, and the wasm file rides along in the package

Satori implements its own layout engine based on the SVG 1.1 spec and supports a limited subset of HTML and CSS. A WebAssembly file ships with the package: the files field publishes the whole dist directory plus layout.wasm, and the export map exposes ./layout.wasm next to the main, ./standalone, ./experimental, ./jsx, and ./jsx/jsx-runtime entry points. What that costs a reader is specificity: properties outside the subset have no fallback here, so a template leaning on them comes out rearranged rather than refused.

JSX has to be pure and stateless, or it will not run

The element you pass must be pure and stateless. Custom React components are fine, but the APIs that make a component dynamic are not supported, and the README names useState and useEffect as unsupported, and allows dangerouslySetInnerHTML only on <style> and <script>. There is no state transition between render and output, no fetching inside the tree, and no way to hand it a server rendered HTML string and have that analyzed. Every value a card shows has to exist before the call. For teams that do not want React in the dependency tree, an experimental builtin JSX runtime can be enabled per file with @jsxImportSource pragmas instead of a global setting.

No <input>, no cursor, no <style>, nothing fetched at render time

HTML support is deliberately narrow, and the reason offered is Satori's own use case rather than a browser's. Only static and visible elements and properties are implemented. The README puts the cursor property out of consideration; text inputs show their value or placeholder and <style> elements apply their CSS, but external resources pulled through <link> or <script> are not loaded. The complete set of supported elements and their preset styles sits in a source file, src/handler/presets.ts, rather than in prose. The consequence for an author is a render closed to the network: nothing is fetched at render time, so whatever a card needs must be inlined or passed in, and gaps have to be found by comparing your templates against that file instead of by reading an error.

Fonts and images come in as data, never as a link to resolve

Fonts arrive as buffers, not as family names the renderer resolves on its own. Each entry in the fonts array carries a name, data, a weight, and a style, and the comment in the README says where the buffer comes from: read the file with fs in Node.js, or use fetch, then provide a Buffer or ArrayBuffer. A family you forget to pass has no source inside the render, so text naming it is yours to catch. Images follow the same reasoning, and for that reason the README pushes encoded data: base64 encoded image data, a buffer, or an arrayBuffer supplied as props.src avoids extra I/O inside Satori when you are heading for another format such as PNG. A background-image is stretched to fit its element unless you set the size.

The SVG is not promised to match what a browser renders

Satori does not promise that its SVG will match browser rendered HTML output, and it gives the reason without hedging: it implements its own layout engine based on the SVG 1.1 spec. That limit shapes how the tool should be used. Text arrives as paths, so glyph metrics come from the font you supplied instead of a system font stack, and anywhere the browser and Satori disagree the difference is yours to inspect. For social cards that means a visual check per template.

Canvas WebGL sits behind satori/experimental and runs shaders on the CPU

The canvas element has a WebGL path, and it is the most experimental corner of the library. It is reachable only from satori/experimental, chosen so it does not add to the size of the satori import, and the README warns it may change or be removed in any release. Each canvas gets a new WebGL2 context that is destroyed along with everything drawn into it, unless you pass a createWebGLContext(width, height) option and supply contexts yourself, which Satori then leaves alone. Contexts come from OffscreenCanvas in browsers and Web Workers. In Node.js 20.16+ it loads the gl package from your project, which must be a WebGL2 build of headless-gl such as an ANGLE and SwiftShader one, shaders run on the CPU there, and bundling server code means keeping gl external and shipping its files in the deployment.

Three releases on one day, and a version placeholder in package.json

Release activity is high and the version numbers move fast. Three releases landed within two days: 0.63.0 on October 19, 2026, then 0.63.1 and 0.63.2 on October 20, and the last push to the default branch main followed on October 23. For anyone whose images render in production, that cadence is an argument for pinning an exact version instead of floating on a range. The published package is MPL-2.0, and the version field in package.json reads 0.0.0-development.2, a placeholder rather than a shipped release, with release.config.cjs in the root and a pnpm workspace, turbo.json, and two vitest configs alongside it. A playground directory in the repository matches the homepage og-playground.vercel.app, which is the fastest way to see a template render before it goes near a server route.

Editorial conclusion

Satori fits teams generating Open Graph cards, social images and server rendered SVG where the layout is Flexbox and the content is fixed. It is the wrong tool for anything that depends on state, effects, or the wider CSS surface. Before adopting, check the supported element list in src/handler/presets.ts against your own templates, confirm your deployment can ship the gl package if you need canvas WebGL, and pin an exact version, since 0.63.0, 0.63.1 and 0.63.2 landed on October 19 and 20, 2026.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. vercel/satori on GitHub