mrkeyoor.com_
Sat 26 Sept 21:07 UTC
Dev Toolsevaluationupdated 25 Aug 2026

takumi review

Takumi is a Rust rendering engine that turns JSX, HTML, CSS, or a JSON node tree into social images, animations, SVG, and paged PDF without launching Chrome. JavaScript packages run through native bindings or WebAssembly, while Rust applications can embed the engine as a crate.

+15stars / 7d
Verdict

Our Takumi checkout installed 950 packages and used 1,687 MB, then its root build and example-heavy test command both failed within 12 seconds. The published packages still deserve a focused trial for browserless OG images or structured PDFs because the API and supported output range are unusually broad. Keep Puppeteer when page fidelity matters, and require golden-image plus PDF validation before production.

We ran it

Lab card: what happened when we ran takumiScreenshot of takumi (takumi.kane.tw)
Install✓ · 45s950 packages · 1687 MB
Build✗ · 11s
Tests✗ · 12sran, no count parsed
Repo1795 files~175,142 lines of source · 51.6 MB · 3 CI workflows

Answers from our run

Does takumi build from source?

Dependencies installed in 45 seconds (950 packages), and the build failed. We cloned commit 9f3ba79 into a clean Debian container with 3 CPUs and no project-specific setup.

Do takumi's tests pass?

The test command failed in our container, and its output did not report a pass or fail count.

Who should not use takumi?

Anyone converting arbitrary web pages pixel for pixel: the README says Takumi supports less CSS than Chrome and recommends Puppeteer for complex pages.

What are the alternatives to takumi?

Satori, Puppeteer, React-pdf. Our Takumi checkout installed 950 packages and used 1,687 MB, then its root build and example-heavy test command both failed within 12 seconds.

Setup3/5Small consumer API, but a 1,687 MB checkout failed build and tests
Docs5/5Detailed APIs, migrations, limits, architecture, and comparisons
Community4/52,879 stars, fresh releases, and active issues and PRs
Maturity3/5Adopted renderer, offset by failed root and integration commands

Who it’s for

Web teams generating many Open Graph cards from JSX, HTML, CSS, or Tailwind utilities.
Services that need searchable, selectable, tagged PDFs without installing a browser.
Cloudflare Workers developers who need image or PDF rendering inside a WASM size limit.
Rust developers who want the same layout and rendering core without a JavaScript process.
Teams replacing Satori or next/og while keeping a similar component-based API.

Who it’s NOT for

Anyone converting arbitrary web pages pixel for pixel: the README says Takumi supports less CSS than Chrome and recommends Puppeteer for complex pages.
PDF templates that require filter: blur(), drop-shadow(), or backdrop-filter: the PDF backend does not support them.
Users expecting system fonts to appear automatically: only a last-resort Latin font is built in, so other fonts must be supplied as URLs or bytes.
Contributors who need a clean root workflow on this snapshot: our Bun build reported that no workspace packages matched *, and the test command failed across example integrations.
Teams unwilling to test target-specific native binaries and WASM behavior across every deployed runtime.
Low-level PDF drawing users who already fit PDFKit well: Takumi trades direct positioning for HTML, CSS, and pagination rules.

Setup reality

Our Bun install succeeded in 45 seconds, adding 950 packages and using 1,687 MB. The checkout at commit 9f3ba79 contained 1,795 files, about 175,142 source lines, and 51.6 MB. The root build failed with exit 1 after 11 seconds; tests failed with exit 1 after 12 seconds.

Consumers install takumi-js for images or takumi-pdf for documents. Node and Bun use native bindings prebuilt for listed macOS, Linux, and Windows architectures; browsers and Cloudflare Workers use WebAssembly. Fonts beyond the fallback Latin face must be loaded. Remote assets should be fetched before rendering when replacing Puppeteer.

The build log says bun --filter '*' run build found no matching workspace packages. The test tail shows failed Waku SSR, Cloudflare Workers, and TanStack Start integration files, plus one skipped Cloudflare test, but only says their builds failed. The excerpt omits the underlying build errors, so we cannot assign a cause.

One renderer produces images, animation, SVG, and PDF

Takumi accepts JSX, HTML strings, or serialized node trees and runs them through a Rust layout and painting pipeline. Static output includes PNG, JPEG, WebP, ICO, and SVG. A time axis turns CSS animation into GIF, APNG, animated WebP, or raw frames for video work. A second vector backend produces paged PDF with selectable text, embedded subset fonts, links, metadata, outlines, attachments, tagged structure, and repeating headers or footers.

Our checkout at commit 9f3ba79 was 51.6 MB across 1,795 files and about 175,142 source lines. The monorepo holds the Rust core, raster and PDF backends, native Node bindings, WASM packages, JavaScript wrappers, documentation, and many framework examples. That is a large source tree for a renderer, but the parts support genuinely different runtimes and output formats rather than wrapping one browser executable.

CSS coverage is broad and deliberately short of Chrome

The image engine supports Flexbox, Grid, block, inline, floats, complex selectors, variables, calculations, media queries, gradients, masks, clipping, blend modes, SVG filters, and Tailwind v4 utilities. Typography includes text fitting, balanced wrapping, bidirectional text, CJK glyph selection, emoji, and text on a path. This is substantially more than the subset many social-card renderers accept. It is still an independent implementation of web styling, so browser parity is the wrong expectation.

The 950-package installation took 45 seconds and occupied 1,687 MB in our full workspace. An application adding takumi-js is a narrower dependency decision, especially when it receives a prebuilt native binding. Compatibility work shifts from managing Chrome to checking Takumi's CSS and asset rules. Templates should use a tested subset, pin package versions, and compare rendered output after upgrades. Arbitrary pages with scripts and browser layout quirks remain Puppeteer's territory.

PDF pagination is the strongest reason to move beyond Satori

Takumi's PDF package understands forced breaks, break avoidance, widows, orphans, repeated table headers, shared column widths, counters, bookmarks, tagged structure, and PDF/A or PDF/UA targets. Factur-X XML can be attached for electronic invoices. The same HTML and CSS vocabulary can drive an OG image and a customer invoice, which reduces the number of template systems a web team maintains.

The README also names hard limits. PDF output lacks blur, drop-shadow, and backdrop filters. Remote assets must be preloaded when moving from Puppeteer. Only a fallback Latin font ships, so Arabic, CJK, emoji, brand typography, and variable fonts require explicit loading. The project says its WASM artifact is 1.5 MB gzip, a project claim we did not independently size. Buyers should run veraPDF and accessibility checks on their own documents instead of relying on feature labels.

Native bindings and WASM cover many runtimes

Node and Bun use native binaries for macOS, Linux with glibc or musl, and Windows across x64 and ARM64. Browsers and Cloudflare Workers load WebAssembly. Rust users can add the crate directly. A next/og-compatible ImageResponse lowers migration work, while helpers load Google Fonts or register reusable fonts on a persistent renderer. This is a sensible distribution strategy for server, edge, browser, and native applications.

Our lab used Bun in an unprivileged Node 22 Debian container with 3 CPUs and 8 GB of RAM. Installation succeeded, so the 1,687 MB dependency tree resolved in that environment. The later failures mean the complete contributor workflow did not reach a clean baseline. Product evaluation should test the exact runtime package rather than treating one Linux monorepo run as proof for every native target or Cloudflare deployment.

What happened when we ran it

Our run at commit 9f3ba79 installed 950 packages in 45 seconds. The build failed with exit 1 after 11 seconds because bun --filter '*' run build reported, No workspace packages matched the filter "*". The root manifest does declare several workspaces, but the log gives no further explanation. We report the mismatch and do not guess whether it comes from Bun behavior, repository configuration, or this checkout.

The test command failed with exit 1 after 12 seconds. The tail shows failed integration files under Waku SSR and TanStack Start, while the Cloudflare Workers example reports a failed build and one skipped test. Each visible failure ends with Build failed with 1 error, without the actual error text. The repository had 3 CI workflow files, pnpm-style monorepo signals, no Dockerfile, and no top-level tests directory in our lab inventory.

Active releases do not erase the failed snapshot

GitHub showed 2,879 stars, 14 open issues and pull requests combined, and a push on August 25, 2026. The latest published release was takumi-pdf@0.11.3 on August 23. Recent pull requests cover Tailwind parsing, CSS variables, stylesheet behavior, and a wider package release. Named users in the README include established documentation, event, and social platforms, useful evidence that the renderer solves production jobs.

Documentation is excellent. The README gives working image, PDF, animation, SVG, font, API-route, and Rust examples, then states when Satori, Puppeteer, React-pdf, or PDFKit is the better fit. Separate docs cover migrations and comparisons. That candor makes the project easier to evaluate. The next maintenance priority for a new contributor is still reproducing why the 11-second root build and 12-second test command failed.

Choose Takumi for controlled templates, not arbitrary pages

Takumi fits generated assets whose markup your team owns: social cards, invoices, certificates, reports, and branded animations. Start with one existing Satori or PDF template, provide every font and remote image explicitly, and compare output across languages and runtimes. For PDFs, verify text selection, page breaks, links, tags, archival conformance, and printer output. For images, keep golden fixtures that catch layout or shaping changes.

The full 1,687 MB contributor install is heavy and our root commands were red. That blocks an unconditional recommendation for this snapshot. The published API remains compelling because one browserless core covers far more than OG-image SVG. Use it where templates are constrained and deployment size matters. Use Puppeteer when the input is a real web page, and use PDFKit when direct drawing gives you more control than CSS.

Alternatives

ProjectWhat it isPick it when
SatoriA JSX and CSS renderer focused on producing SVG for social images.pick this instead when SVG and the established `next/og` ecosystem cover the whole job.
Puppeteer gh↗Browser automation through Chrome or Firefox, including full-page PDF and screenshot output.pick this instead when browser-faithful CSS and JavaScript execution matter more than deployment size.
React-pdfA React renderer for PDF documents using its own page and text primitives.pick this instead when you want a PDF-specific React model and do not need Takumi's shared HTML and image renderer.
PDFKitA mature JavaScript PDF library with direct drawing and document primitives.pick this instead when precise low-level drawing is easier than expressing the page in HTML and CSS.

What people are saying

  1. [github-trending] kane50613/takumi

Sources

  1. Takumi README
  2. Takumi repository
  3. takumi-pdf 0.11.3 release
  4. Takumi documentation

More dev tools reviews

terminal-browser · fearless_simd · devops-exercises · scriptc · 30-seconds-of-code · styleguide · the whole board →