Thumbnail Maker

Read the guide: On-device background removal, verifiably local walks through the subject cutout's model, the files it loads, and the DevTools check one step at a time. The sections below document the rest of the maker — the engine, the presets, the export planner, and the autosave — with every figure computed at build time by the same code the editor runs. The other guides cover the downloader, the tester, and the size rules.

Everything runs on your device — verifiably

The entire editor is client-side: the canvas, the templates, the undo history, the autosave (this browser's localStorage), and — unusually — the background removal. The subject cutout runs Google's open-source MediaPipe selfie-segmentation model inside your browser, from model files this site hosts itself. Your face never leaves your browser. That is a checkable claim, not a slogan: open DevTools, watch the network panel while you edit and cut out a photo, and you will see no image bytes leave the page. The methodology page documents the model version, its Apache-2.0 license, and the exact security-policy change that running it required.

A pure engine driving a canvas

The maker is split in two, and the split is what makes its behaviour documentable. A pure engine — plain functions with no access to the page — owns every decision: the document model, the transform geometry, the undo history, the templates, and the export planner. The browser layer does only what a browser must: it draws the current document onto a <canvas>, forwards pointer and keyboard events to the engine, and encodes the final image. Nothing in the drawing code decides anything, and nothing in the engine touches the screen, which is why the engine can be tested against hand-computed cases and why the figures on this page can be produced by calling it.

A document is a canvas size (whole pixels, from 64 to 4096 on each side), a background (a solid colour, a two-colour linear gradient with an angle, or an image), and an ordered stack of layers painted from the bottom up. The layer types are image, text, and shape (arrow, badge, or box), and every layer carries the same transform box: a centre point, a width and height, and a rotation about the centre. Every operation the editor performs — add, remove, duplicate, raise or lower, patch a property, change the background — returns a new document rather than mutating the old one, and any layer that is added or patched is re-validated on the way in. A patch that would set a text size below the minimum, a colour that is not a hex value, or an image source that is not local is refused before it can reach the canvas.

Undo and redo follow the same rule. Each recorded state is the serialized document; the history keeps the last 60 of them, and a state identical to the present one is not recorded at all — a drag that ends where it started leaves no undo step. Recording clears the redo stack, as in every editor. Those statements are asserted while this page builds: a fresh history has nothing to undo, recording the same document twice yields the same history, and undoing the first edit returns exactly the blank canvas with a redo step waiting.

A worked figure shows how much the engine derives from the canvas rather than storing. Pressing "+ Text" on the 1280×720 canvas creates a layer centred at (640, 360), set in Archivo Black at 86 px with a 6 px outline and a wrap width of 1152 px; the engine's starter box before the editor measures the rendered text is 768×108 px. Each is a fraction of the canvas, so the same button on a different canvas normally gives different values. The font size and the outline are the exception at the small end: both carry a floor for tiny canvases. On the smallest canvas the engine accepts, 64×64, the starter text is set at 24 px with a 2 px outline; a 128×128 canvas gets the same two values while its starter box (before measurement) grows from 38×10 to 77×19 px.

Canvas sizes: the 3 platform presets

The ratio column is computed by the same describeRatio function the tester uses to judge uploads, and the filename column is what an export from a blank canvas of that size is saved as — the dimensions are in the name, so files for different platforms cannot be confused with each other.

Switching canvas does not crop. The engine rescales every layer by the smaller of the two axis factors, so nothing overflows, and re-centres the composition in the new frame; font sizes, outline widths, shadow offsets, and feather radii scale by the same factor. Starting from the text layer above on the 1280×720 canvas: on the Shorts / Reels / TikTok canvas (1080×1920) it lands at (540, 960) at 72.56 px; on the Instagram post canvas (1080×1080) at (540, 540) at 72.56 px. One consequence is worth knowing before you rely on it: a switch is not reversed by switching back. Returning to 1280×720 from the vertical canvas applies the smaller factor again, and the same text layer comes back at 27.21 px. Use Undo, which restores the recorded document, rather than the canvas menu.

Templates, honestly: deterministic layouts, not AI

The 10 starting layouts — Shock, Versus, Tutorial, Drama, Listicle, Reaction, Before / After, Gaming, Minimal, Question — are what the industry calls "emotion presets", built the honest way: as fixed templates of generated primitives (gradients, outlined display text, arrows, badges, and clearly labeled photo slots). No AI generates them, and that is a feature. They load instantly, they are identical every time, they cost nothing to run, and no prompt or image is sent anywhere. Their descriptions tell you what each layout does, and nothing else.

Each template is a function from canvas size to document, so the same template on the vertical canvas places its layers at the same fractions of the frame rather than stretching the YouTube version. Every one is validated by the same rules as a hand-built document while this page builds, which is where the layer counts above come from. The photo slot is an honest placeholder: a translucent, outlined rectangle named "Subject slot — import your photo here, then delete me" that you import a photo over and then delete — 10 such slots across the 10 templates. No template contains a photograph, because none of them is copied art.

Moving layers: hit tests, snap guides, and the canvas clamp

Pointer handling is geometry, not guesswork. To decide whether a click landed on a rotated layer, the engine maps the pointer into the layer's own unrotated space and compares it with the box, so a tilted text layer is selectable along its real outline rather than its axis-aligned bounds. The 8 resize handles keep the opposite handle or edge fixed in place while you drag; corner handles preserve the layer's proportions by default, edge handles change one axis. The rotation grip snaps to the straight and diagonal stops when the drag comes close to them, so squaring a tilted layer takes no precision.

Snap guides work the same way. While a layer is dragged, the engine compares its centre with the canvas midlines and thirds on each axis and, when the centre comes within a small threshold, moves it onto the line and reports which guide to draw. Computed here for the 1280×720 canvas: a centre 5 px right of the midline snaps to x = 640 with 1 guide drawn; one 3 px past the left third snaps to x = 426.67; one 40 px from every line is left alone (0 guides). At most one guide per axis applies — the nearest. Separately, a layer's centre is clamped to the canvas: dragged far past the bottom-left corner, its centre stops at (0, 720) instead of vanishing, so a layer can overhang an edge for effect but can never be lost off-screen.

The subject cutout: an on-device model

Toggle the cutout on a photo layer and the maker runs Google's open-source MediaPipe selfie-segmentation model against the image inside your browser. It is a model built for people: for each point of the mask it produces, at the model's own resolution, it estimates the confidence that the point belongs to a person; the maker scales that mask to the photo and uses the confidence as opacity — fully opaque where the model is sure it is a person, fully transparent where it is sure it is not, graded in between. The result is stored in the layer as a PNG alongside the original, so the toggle can be switched off without re-importing. The feather control blurs that mask by the radius you set, in pixels, before the source is composited through it; at zero the edge is hard.

That is also where it stops. A selfie-segmentation model is built for people; for a product, a pet, or a landscape, use the standalone background remover, whose "Click the subject" mode and "Best quality" tier run the same local-first way and are described on the methodology page. That page also gives the model version, its Apache-2.0 licence, the byte sizes of both model files this site hosts under /vendor/mediapipe/, and the one content-security-policy addition WebAssembly required; the background-removal guide's file table measures the runtime as well. If the files fail to load — an extension blocks WebAssembly, or the fetch is interrupted — the cutout toggle disables with a message and every other part of the editor keeps working.

The privacy claim is checkable rather than promised: with DevTools open on the network panel, importing a photo and toggling the cutout produces requests only for the runtime and model files from this site, and none carrying image bytes. The guide On-device background removal, verifiably local shows exactly what to look for.

Exports: the cap, the planner, and decode verification

Every export runs under a size cap you choose. The default is 2 MB, and the list offers the higher caps with their platform context in the label:

Cap	Shown in the export panel as	Exact limit in bytes
2 MB — safe everywhere (YouTube’s mobile-upload limit)	2.00 MB	2,097,152
10 MB — YouTube podcast thumbnails	10.00 MB	10,485,760
50 MB — YouTube desktop uploads	50.00 MB	52,428,800

Those figures are the upload limits our size guide checked against Google's own help documentation (verified July 25, 2026). The maker carries the limits as engine data, and this page reads the verification date from the guide's source while it builds, so neither is retyped here. The default is the mobile-upload figure because it is the one that satisfies every upload path at once.

One unit detail matters at the margin. The maker reads each cap in binary megabytes of 1,048,576 bytes — the basis the export panel's size display also uses — so the default cap admits a file of up to 2,097,152 bytes. Read in decimal megabytes of 1,000,000 bytes, the same 2 MB figure stops at 2,000,000 bytes, 97,152 bytes lower. The export panel states each file's real size after encoding; if the stricter reading is the one your upload path applies, keep that displayed size below 1.91 MB.

Format is recommended from what the document contains, not guessed. With a photo layer or an image background present the hint reads "This design contains photo imagery — JPG compresses photos far better, and thumbnails need no transparency." With text and shapes only it reads "This design is flat graphics and text — PNG keeps hard edges crisp and is usually smaller than JPG for this kind of image." A hidden photo layer does not count. PNG has no quality dial, so a PNG over the cap is simply reported with its real size and the suggestion to switch to JPG.

How the JPG planner converges

JPG has a quality setting and no way to ask for a byte size directly, so the maker searches. The browser encodes once; the pure planner looks at every attempt so far and answers with one instruction: encode again at a specific quality, stop with the best fit, or report that the cap is unreachable. The search has two phases. Until something fits, each probe is half the lowest quality that overshot, floored at the planner's minimum; once a fit exists, the planner brackets between the highest quality known to fit and the lowest known to overshoot and halves that gap each round. It stops early when an attempt lands within a narrow band under the cap, when the bracket has collapsed to a quality already tried or too narrow to split, or when a fixed attempt budget runs out. Below, the planner is driven against a stand-in encoder whose output grows with the square of the quality setting. The byte counts are illustrative — a real encoder's sizes depend on the image — but the sequence of qualities is the planner's actual output for those inputs, against the 2 MB cap.

The planner stops after 5 encodes at quality 0.534 with a 1.85 MB file, and the export panel reports the setting it settled on (shown as 53) and the 5 encodes it took. A design that fits at the first, highest-quality encode is accepted on the spot — the cap is a ceiling, not a target, and nothing is inflated to fill it. When nothing can fit — here, a stand-in encoder that overshoots at every setting — the search closes in on the quality floor and stops:

After 5 encodes with no fit, the planner reports the smallest attempt (2.32 MB at quality 0.059) as unreachable, and the editor says so and offers no file. Choosing a larger cap or removing layers is the only fix; the tool never quietly hands over an oversized export.

Decode verification and the filename

Before the download button appears, the encoded bytes are decoded again and their pixel size is compared with the document — the same decode-verify rule the downloader applies to YouTube's files. For the blank 1280×720 canvas the passing message reads "Verified: the file decodes to 1280×720 pixels." Had the file decoded to half size, the export would be withheld with "Export verification failed: expected 1280×720 but the encoded file decodes to 640×360. The download was not offered." The size shown beside the download is the byte count of the file you are about to save, measured from the encoded bytes rather than predicted, and the file is named with its dimensions: thumbnail-1280x720.jpg or thumbnail-1280x720.png here.

Autosave, and why corrupt data is rejected

Every committed edit schedules a save of the serialized document to this browser's localStorage — nothing is sent to a server, and clearing the site's data removes it. On the next visit the editor reads the saved string back through the same parser that validates imports, and only a document that passes every check is restored. Anything else is discarded, the editor reports that the saved design could not be read, and it starts fresh rather than drawing a broken document. Imported photos are inlined so a document is self-contained, which is also why a design can outgrow the browser's storage: if the browser refuses the save, the autosave note says so and advises exporting a copy, and the parser refuses any string longer than 25,165,824 characters outright.

Each sentence in that table is the engine's own error for that input, produced while this page built. The round trip is checked the same way: the example document above, serialized and parsed again, comes back identical to the character.

3 fonts, self-hosted, openly licensed

Display text on a canvas needs the actual font file, so the maker ships its faces rather than relying on whatever the viewer's system has. All 3 are SIL Open Font License releases, served from this site (no fonts CDN, so your font choice cannot be tracked), with versions and license texts pinned in the repository and summarized on the methodology page. A weight outside a face's range is clamped into it rather than faked.

Frequently asked questions

Design responsibly: use photos you have rights to. The maker's engine — document model, transform math, history, templates, and the export planner — is pure, tested code documented on the methodology page.