Turn any URL into a fillable PDF — or a screenshot.

Yes — that is snapdok.io's specialty. Send "format":"pdf","pdf_forms":true and the form controls on the page become real AcroForm fields in the PDF: text, email, tel, date, password, number, textarea, checkboxes, radio groups and dropdowns. Open the file in Acrobat, macOS Preview or a phone PDF reader, fill it in, save — the values survive reopening. Pages with Chinese text get a font subset embedded automatically, so the fields accept Chinese input too.

It is included in every plan — the free tier too. There is no add-on and no per-feature pricing: a pdf_forms render is metered as one ordinary render, exactly like a screenshot.

The boundaries, stated plainly: file pickers, sliders (range), color pickers, hidden or invisible controls, and JS-built fake widgets (a div styled to look like a dropdown) cannot become PDF fields — they are skipped cleanly and counted in the X-Form-Skipped response header, never placed somewhere wrong. Forms inside iframes are out of reach as well. The PDF is laid out with your page's print styles at paper width, so width does not apply on this path.

curl -X POST https://snapdok.io/v1/render \
  -H "Authorization: Bearer $SNAPDOK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://your-app.com/intake-form","format":"pdf","pdf_forms":true}' \
  --output fillable.pdf

Yes. Add "pdf_form_only":true alongside pdf_forms and the PDF is pruned down to just the form — the fields with their labels, the group headings, and the title or intro text directly above the form. The navigation bar, sidebar, ads and footer are left out. What you get looks like the paper version of the form rather than a printout of a website, and it is still fully fillable.

It refuses to guess rather than cut too much. When the page has no visible controls, only a lone search box, a form wrapping the whole page, controls inside an iframe, or JavaScript widgets built from styled divs, the render falls back to the full page — the exact bytes pdf_forms alone would have produced, never a half-broken cut. The response tells you which happened: X-Form-Extracted is true for the pruned form and false for the fallback, with the reason in X-Form-Extract-Fallback. It is metered as one ordinary render, on every plan.

curl -X POST https://snapdok.io/v1/render \
  -H "Authorization: Bearer $SNAPDOK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://your-app.com/intake-form","format":"pdf",
       "pdf_forms":true,"pdf_form_only":true}' \
  --output form-only.pdf

Playwright driving Chromium — the same engine family your users browse with. JavaScript executes, modern CSS works, web fonts load.

Yes. Navigation waits for the wait_until strategy you choose. For heavy client-side apps use "wait_until":"networkidle", and add "delay":500 if you animate content in after load.

It comes out as text. A stock headless Chromium — on Lambda, in a slim Docker image, on a fresh VPS — ships no CJK fonts, so every ideograph and hangul syllable renders as a .notdef box: □□□, the thing everyone calls tofu. Our render machines have CJK fonts installed, so Simplified Chinese, Traditional Chinese, Japanese and Korean all come back as real glyphs in PNG, JPEG and PDF. PDF output embeds a subset of the font, so the file still reads correctly opened on a machine that has no CJK font at all.

They also come back in the right glyphs. Many Han characters are drawn differently in Japanese, Simplified Chinese and Traditional Chinese even though they share one Unicode codepoint, so a single pan-CJK font makes Japanese text look subtly Chinese to a native reader. We install Noto Sans CJK JP, KR, SC and TC and route by the page's declared language: lang="ja" renders in Japanese forms, lang="ko" in Korean, lang="zh-CN" and lang="zh-TW" in their own. Declare the language on the page and the typography follows it.

You do not have to send anything special — a page that just asks for sans-serif is enough:

curl -X POST https://snapdok.io/v1/render \
  -H "Authorization: Bearer $SNAPDOK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://your-app.com/invoice/zh-CN","format":"pdf"}' \
  --output invoice.pdf

Two ways, both instant. On the Free plan, put your email in the free key form above — no card, and the key appears on the page as soon as you submit. On a paid plan, the key is displayed on the Stripe confirmation page the moment payment clears.

Either way, copy it there and then: for security it is stored only as a hash afterwards, and the readable copy stays on screen for about ten minutes before it is wiped.

You get HTTP 402 with a JSON body explaining which allowance ran out, when it resets and what to do next. Every plan is a hard cap, so nothing is charged automatically and you can never receive a bill bigger than the plan you picked — you decide whether to wait for the reset or move up a plan.

No. Your monthly quota resets each billing cycle and unused requests do not carry over — free keys reset every 30 days from signup, paid plans on your renewal date.

No. An identical request within 24 hours is served from cache, marked X-Cache: HIT, and is not metered.

Not yet — the URL has to be publicly reachable. Cookie and header injection is on the roadmap; tell us if you need it and it moves up.

On Hetzner hardware in Falkenstein, Germany. Rendered files are held in a cache for up to 24 hours so repeat requests are free, then deleted. We store your key as a SHA-256 hash, the URLs you render are not retained beyond that cache window, and payment data lives with Stripe.

snapdok.io is an independent product, not part of a larger vendor. It launched in 2026 with no customers yet, so you would be an early one — which also means your feature requests reach the engineering side directly, without passing through a support tier, and get answered.