What we're building, and what would make us stop.
A phase here is an order of work, not a date. Each one names what it would reuse, the one number Gizlet can actually watch, and the condition under which it does not get built. The Gizlets that exist are on the Gizlet index, and the ones that do not are listed there too.
Flows and recipes
Done. It came first because it tested composition with Gizlets that already existed.
No new Gizlets. The three image Gizlets became one visible, reorderable session with a single download at the end, and a Flow became a link that carries its settings and nothing else.
- one flow graph derived from payload kinds
- settings in the URL fragment, never the query string
Pageviews on the Flows page, which is the one number that says whether chaining Gizlets is a thing anyone wants.
If the Flows page draws fewer visits than the least-visited single Gizlet across a full 30-day window, composition is not the thesis, and the Flow work stops rather than growing.
Shipped and measurable, and not yet judged: the number exists in Cloudflare Web Analytics and nobody has read it. Recipe-link shares are uncountable by construction, because a fragment is never sent to a server — that is the correct trade, and it is why filed issues carry the weight instead.
PDF, the four that matter
Done. It ran before this page existed, which is the order the argument required: ship a capability, then publish the plan.
Four PDF Gizlets chosen for the edges they add to the flow graph rather than for search volume — the two that turn documents into images and back, and the two that take documents apart and put them together. A viewer arrived with them, because reading a PDF without uploading it is the precondition for everything else.
- Compress PDF · not on the bench
- The most-wanted PDF job and the hardest: real compression means re-encoding the image streams inside the document, which the current PDF library does not do. It stays off the bench until a spike proves it can be done on-device, because promising it first would be the whole problem with roadmaps.
- one PDF page tree
- one PDF renderer
- no WASM
- the ZIP writer that hands back many files at once
Pageviews on the four PDF routes, against the image Gizlets that were already there.
If the four PDF routes together draw fewer visits than the single most-used image Gizlet over a 30-day window, PDF is not the demand this assumed, and the next PDF phase does not start.
Shipped. The graph now runs in both directions — a document can become images and images can become a document — which is the property the phases after this one are built on.
The image gaps, on Canvas
Done. It went ahead of work that needed a new dependency, because it needed none at all.
The obvious holes next to the image Gizlets that were already there: cutting a picture down, arranging several into one, turning one upright, setting one on a background, reading what a photo says about you and stripping it out, and reading a colour or a size back off an image without changing it.
- Canvas
- the existing browser image decode and encode helpers
- the existing pixel limits
- no new dependency
Issues filed through the request form that name one of these by name.
If 30 days after this page publishes no filed issue names an image Gizlet, none of these gets built, and the order gets rewritten around whatever visitors did ask for.
Shipped whole: all seven, on Canvas, with no dependency added and the pixel limits the older image Gizlets already kept. The kill criterion never got to run — the phase was built inside the window it was meant to be judged in, which is the honest reading of it rather than a claim that demand was proven. Two of the seven turned out to belong to no Flow at all and say so in the same list as the PDF viewer, and one of them, Remove Image Metadata, needed an EXIF reader written here rather than installed, because a page arguing that your photograph should be seen by nobody cannot fetch a parser to establish it.
The PDF page tree
After the PDF viewer becomes a surface the other PDF Gizlets can reuse. Every Gizlet here needs to show a visitor a page before it can ask them where to put something on it.
The page-level document jobs, all of which are the same two pieces wearing different hats: pick pages, then write something onto them. Reordering and rotating, a watermark, page numbers, a signature you drew yourself, and clearing the fields a document carries about whoever made it.
- Organize PDF
- Watermark PDF
- PDF Page Numbers
- Sign PDF
- Clean PDF Metadata
- one PDF page tree
- the shared PDF viewer and its thumbnails
- one page-range parser
- no second PDF dependency
Issues naming a PDF page job, and pageviews on the PDF routes that already exist.
If the PDF routes that shipped in the phase above stop growing and no filed issue names a page job, the page tree work does not start: five Gizlets sharing machinery nobody has asked for is still five Gizlets nobody asked for.
Text in, text out
Whenever a phase ahead of it is blocked. These need no file handling, no new dependency worth arguing about, and no shared surface, so they are the work that fits in the gaps.
The small conversions and inspections that are a single pure function each: percent-encoding, Base64, a token read without being verified, a file digest, records moved between JSON and CSV, a delimited file read as a table, a timestamp read as a date, identifiers, and a link turned into a scannable square.
- QR Code Generator
- URL Encode & Decode
- Base64 Encode & Decode
- JWT Decoder
- File Hash Generator
- JSON and CSV Converter
- CSV Viewer
- Timestamp Converter
- UUID Generator
- pure functions in one place, unit-tested with no browser
- Web Crypto
- no file leaves the text box
Pageviews on the two text Gizlets that already exist, which are the only evidence that the text half of this site is read at all.
If the existing text Gizlets stay the least-visited routes on the site across two consecutive 30-day windows, none of these nine ships, however cheap it is. Cheap is not a reason.
One archive, three uses
After a Gizlet needs to hand back a folder rather than a file. The ZIP writer that already bundles many images from one document is the seed; this phase generalises it.
Bundling files into an archive, reading one apart again, and the icon set that only makes sense as a folder of files with a snippet beside it.
- Create ZIP
- Extract Archive
- Favicon Generator
- one browser archive layer
- path-safety and size guards shared by every format
- the existing image encoder
Issues naming an archive job, and pageviews on the Gizlets that already hand back a bundle.
If reading a RAR needs a decoder that cannot be lazily loaded and audited, or if no filed issue names an archive job, this phase ships the ZIP half only and the rest is dropped rather than carried.
Video as steps, not a studio
After the image and document phases ship, and after the browser share of visitors who cannot run the required video APIs is actually looked up rather than guessed at.
Three video Gizlets, each a step rather than an editor: keeping the part of a clip that matters, pulling stills out of it, and turning a short clip into a short loop. The stills are the point — they are the edge that joins video to every image Gizlet on the site.
- Trim Video
- Video to Frames
- Video to GIF
- Convert Video and Compress Video · not on the bench
- Both sit downstream of trimming and add no new edge to the graph on their own, so registering them would be counting the same capability twice.
- Extract Audio · not on the bench
- Trivial to build and deliberately absent: it would need an audio category, and a category that exists to hold one unbuilt Gizlet is padding.
- one pure-TypeScript media library
- the browser codec APIs
- no WASM and no ffmpeg
- the existing image encoder for the frames
Browser and device share, which Cloudflare Web Analytics does report, plus issues naming a video Gizlet.
If the required browser codec APIs are missing for a material share of visitors — they are unavailable in every version of one mobile browser — or if no filed issue names a video Gizlet, video does not start. A Gizlet page that fails silently on a visitor’s browser is worse than a Gizlet that does not exist.
What we won't build.
Not a shortlist of things we ran out of time for. Each of these is a job a browser tab cannot do honestly, so each one names whoever does it properly instead.
| Won't build | Why | Use instead |
|---|---|---|
| Word or Excel to PDF | A faithful conversion needs the layout engine the document was written in — fonts, pagination, table breaking, the lot — and that engine is an office suite, not something anyone can send to a browser tab. Every free converter that offers this uploads your document to a server and renders it there, which is exactly the thing this site exists not to do. | The application’s own export, or LibreOffice |
| Remove image background | Cutting a subject out of a photograph needs a segmentation model, and the model has to reach the visitor before it can run: tens of megabytes downloaded to do one job. It may become reasonable, and if it does it arrives behind an explicit opt-in with the download stated in megabytes. What it will never be is switched on by default and called local. | remove.bg |
| Scanned PDF to text | Optical character recognition has the same model-download problem, and a worse one behind it: on a real scan — skewed, speckled, photographed at an angle — on-device accuracy is not yet good enough to be worth the visitor’s time. A tool that quietly returns the wrong text is more expensive than no tool. | Tesseract, which runs on your own machine |
| Certificate-based e-signatures | A signature that means something legally needs a certificate authority, an audit trail, timestamping and identity verification — infrastructure, and infrastructure Gizlet deliberately does not have. Placing a signature you drew onto a page is a different job and an honest one, and it is on the list above under its own name; it is a stamp, and it is never described as more. | DocuSign, or another e-sign provider |
If it needs a server, it isn't a Gizlet.