Skip to content

[email protected]

200OK

PDF Engine: self-hosted PDF to HTML5, templates and a REST API

Our own product: any PDF back as pixel-exact HTML5 with real text, turned into a template a system can fill, on your own server.

Kind
Document conversion and templating product
Our part
Our own product, designed, built and run by 404 Tech, and live for anyone to try.
Open the live product(opens in a new tab)

404 Not Found

What was missing

Businesses keep their documents as PDFs, and their systems need to fill them: an invoice, an application form, a statement. A PDF is a set of drawing instructions, not a page anyone can edit, so the usual answers are to rebuild the form by hand in HTML or to stamp values onto a picture of it. Both drift from the original. What was missing was a way to get a PDF back as real, selectable HTML at the exact page size, mark where the values go, and fill it from the business's own system, on its own server.

Constraints

What the system had to hold to, before a line was written.

Fidelity
Every page comes back pixel-exact with real text. Nothing is baked into a picture, so it can be selected, searched and read aloud.
Hosting
Self-hosted: one container image on the customer's server or private cloud. Files stay where they are put and are purged on the customer's schedule.
Templates
A template must fit the system that fills it: Handlebars, Jinja, Liquid, or the customer's own placeholder style.
Integration
Anything a person does in the portal is also one REST request, with a key per integration and usage counted per key.
Migration
Existing integrations switch over by changing one URL, because the older convert endpoints stay drop-in compatible.

The system

People work in a browser portal; other systems call a REST API with a key of their own. Both hand jobs to the same engine, with its workers on the same host. The converter takes each page apart into text runs, vector paths and images, each on its own layer at an exact coordinate, and rebuilds every text run as a positioned HTML5 element with its real font, size and spacing. Template Studio places variables on that page and exports a template in the syntax the receiving system already uses. Around the core sit 22 page and image tools on the same engine. A job is submitted, polled and collected from a short-lived link, and results sit on a storage volume that is purged on schedule. The public page adds an inspector that opens a PDF in the visitor's own browser, so nothing is uploaded.

Figure 1Drawn from the build
Customer network,one container imageon devicesign inAPI keyjobsjobsconvertexporttoolsresultsshort-lived link01Peoplein a browser02Inspectornothing uploaded03Your systemkey per integration04Portalconvert, studio, tools05REST APIsubmit, poll, collect06Engineworkers, credits, limits07ConverterPDF to HTML5 layers08Template exporthbs, Jinja, Liquid, own09Page tools22 tools, one engine10Storage volumepurged on schedule

Portal and REST API → one engine → converter, template export and page tools. Results wait on a purged volume and go back through a short-lived link, inside the customer's network.

  • Built by us
  • Data held
  • Third party
  • Offline or out of band
Read the drawing as text

Parts

  1. 01People: in a browser
  2. 02Inspector: nothing uploaded
  3. 03Your system: key per integration
  4. 04Portal: convert, studio, tools
  5. 05REST API: submit, poll, collect
  6. 06Engine: workers, credits, limits
  7. 07Converter: PDF to HTML5 layers
  8. 08Template export: hbs, Jinja, Liquid, own
  9. 09Page tools: 22 tools, one engine
  10. 10Storage volume: purged on schedule

Flows

  • People to Inspector: on device (alternate or out of band)
  • People to Portal: sign in
  • Your system to REST API: API key
  • Portal to Engine: jobs
  • REST API to Engine: jobs
  • Engine to Converter: convert
  • Engine to Template export: export
  • Engine to Page tools: tools
  • Engine to Storage volume: results
  • Storage volume to REST API: short-lived link (alternate or out of band)

The screen

The live product's public pages, captured at desktop width.

PDF Engine home page: the headline "Turn any PDF into a template you can fill", buttons to get started or see Template Studio, and counts of 22 tools, 4 template styles and 1 call per job, beside a page drawn as a stack of layers.
Home page
Tour step 1, Disassemble, headed "Every page is a stack of parts": a page drawn as four stacked layers labelled text, vectors, images and page, the page measured at 210 by 297 mm.
Disassemble: every page as a stack of parts
Tour step 4, Template: Template Studio lists four variables (customer name, invoice number, issue date, total) beside an invoice page whose fields hold placeholders, with export buttons for Handlebars, Jinja, Liquid and your own style.
Template Studio
Tour step 7, Deploy, headed "And all of it happens inside your walls": inside a frame labelled your network, a browser portal and your backend with an API key feed PDF Engine, which passes work to workers and results to a storage volume purged after 24 hours.
Deploy: inside the customer network
The inspector, headed "Drop a PDF and see its skeleton": a sample sheet pulled apart into text, vector and image layers in the browser, with counts of 1 page, 42 text runs, 3 fonts, 1 image, 19 vector paths and a 3 KB file.
The inspector, run on a sample sheet

Decisions

The engineering calls that shaped the build, and why each one was made.

  1. Text stays text.

    Each text run becomes a positioned element with its real font, size and spacing, never a picture of the page. The output stays sharp at any zoom, and people can select it, search it and have it read aloud.

  2. One engine behind the portal and the API.

    The portal and the REST API run the same tools against the same credits and limits, so anything a person can do in the browser, a system can do in one request.

  3. Templates in the receiver's syntax.

    Template Studio exports Handlebars, Jinja, Liquid or a custom placeholder style, so the template drops into the system that fills it instead of that system learning a new one.

  4. Self-hosted by design.

    One container image, files kept where the customer puts them and purged on their schedule. A document never has to leave the building to be converted.

  5. A try-it that uploads nothing.

    The public inspector opens a PDF in the visitor's own browser and pulls page one apart into its layers on their machine. No upload, no account.

200OK

Shipped

A live product: a browser portal with PDF to HTML5, Template Studio and the tool library, plus a REST API with a key per integration. It deploys as one container image, and plans are paid in credits, with every tool showing its cost before it runs.

Counts taken from the live product and its published licence list. Counted on 3 November 2026. No figure here is a business result.
FigureWhat it counts
22page and image tools in the tool library
4template syntaxes Template Studio exports
39open-source components in the web app, each licence passed on
1container image to deploy
25 MBlargest PDF the in-browser inspector opens, without uploading it

Built with

  • Nuxt 4
  • Vue 3
  • Tailwind CSS
  • DaisyUI
  • pdf.js
  • three.js
  • GSAP
  • ECharts
  • REST API
  • Container image