Methodology · Claims and limits

How Depth Paper works, and where its claims stop

Every wallpaper site says its downloads fit and its tools are private. Those sentences cost nothing to write, so this page does the more useful thing: it states exactly what this site claims — sizes from twice-verified data, wallpapers reproducible from a visible seed, computation that stays in your browser — and then spends longer on where each claim stops. It opens with the reproducibility claim running live, so at least one of them is checked in front of you rather than asserted.

Seed Palette Pixels compared Differing Verdict

The engine below is the shipped engine. This page loads the same mesh.js file the maker and the gallery run — loaded, not copied — and evaluates your chosen seed twice from scratch: two separate field constructions, two separate pixel buffers. Every byte of one is compared against every byte of the other before either is painted. The readout is the result; the canvases are the two buffers that were compared.

Render A
Render B

How this demonstration works

The check above compares two complete, independent evaluations of one recipe. Pressing the button builds the gradient field twice — separate seeded point placement, separate color assignment, separate grain — and renders each into its own buffer at 168×364 pixels: 61,152 pixels, 244,608 bytes per render. The comparison walks every byte of both buffers and counts disagreements; the readout reports the count and the verdict, and the probe line prints one pixel's red, green, and blue values from each render so you can see two actual numbers agree rather than trusting a summary.

It comes out identical because nothing in the engine depends on anything but the recipe. The seed drives a small deterministic random generator that places the control points; the blend is inverse-distance interpolation; the grain is an integer hash of each pixel's coordinates and the seed. All of it is integer and IEEE-754 double arithmetic in a fixed order — no clock, no extra randomness, no hidden state — so the same inputs produce the same numbers every time. The canvases are painted from the very buffers that were compared, at a small size because composition scales with the canvas: a full-resolution export of the same seed is the same picture at a higher sampling density.

What this proves is bounded, and the bound is worth stating: two renders compared inside your browser prove that your browser, at this size, right now, evaluates the recipe identically twice. The stronger claim — that any browser computes the same field values — rests on the arithmetic being fixed-order operations with no platform-dependent step, which is an argument from how the engine is written, not something one page can measure from inside a single browser. And the finished PNG file is outside the claim entirely: encoding is done by each browser's own encoder, so identical pixels can become differently compressed bytes.

What this site claims

Four claims. Each is stated here in its strongest honest form, and the longest section on this page is the one about where they stop.

Exports are exactly sized. Every download is rendered at the native panel pixels of the device you picked, taken from a table compiled by hand in which each entry was cross-checked against two independent published sources before it appeared. The maker's device picker and both size charts read the same data file, so the tool and the charts cannot disagree with each other.

Every wallpaper is reproducible from its visible seed. A seed plus a palette, a point count, and a size is the complete recipe: nothing else influences a single pixel. Deterministic field values are what the engine is built to give, and the demonstration above evaluates that claim rather than illustrating it.

Nothing you make or load here leaves your browser. The gradients are computed inside the page, and the two photo tools read a photo through the file picker and measure it on your device. There are no uploads, no accounts, and no analytics, and the site's security policy makes your browser refuse requests to any other origin.

Everything rendered here is original. The palettes are authored for this site, the compositions come from seeded arithmetic, and no image assets exist anywhere on the site — the gallery is a list of recipes rendered live. No model generates anything, and nothing is traced, sampled, or recreated from anyone's artwork.

Where the device sizes come from

The device table is a plain, versioned data file compiled by hand. Every entry — native pixels, logical points, aspect ratio, release date — was cross-checked against two independent published sources before it appeared, and those sources are recorded next to each device family inside the file itself, so the provenance ships with the data rather than living in someone's memory.

The table changes only through reviewed commits. Nothing on this site fetches sizes from anyone's endpoint at runtime — there is no request to make, and the site's security policy would refuse one anyway. It is updated as new devices ship and their specifications are published, and each entry carries its device's release date, so the table's own coverage is inspectable on the size charts.

Both size-chart pages are generated from this table by an authoring tool, never edited by hand, and an automated check fails the site's build whenever a shipped chart differs from what the table currently says — a stale chart cannot ship silently. The maker, the pair tool, the gallery, and the depth-effect checker read the same module, so every screen dimension you see anywhere on this site has exactly one source.

What the table is, precisely: a snapshot of published specifications as of its last commit. That framing matters. A brand-new model can be absent for a time, and the honest fallback is the maker's custom size option — 240 to 4096 pixels per side, out-of-range values clamped and reported — which covers any screen the table does not yet name.

What a seed reproduces

A seed on this site is not a label — it is the complete input. The engine seeds a small deterministic random generator with that one integer, and everything follows from it: how many control points there are, where they sit, which palette color each carries, how far each one reaches, and the fine grain that keeps smooth gradients from banding on OLED screens. Same seed, same palette, same point count, same size: same wallpaper, on any visit.

This is why gallery entries and shared links are recipes rather than pictures. The seed rides the URL on every tool, an entry in the gallery is a seed–palette–points tuple, and "open in maker" hands the recipe over as parameters. Nothing needs to be stored to be permanent here: the arithmetic is the archive.

The scope of that promise is field values — the numbers the engine computes for every pixel. Byte-identical PNG files across different browsers are explicitly not promised: the finished pixels are handed to your browser's own PNG encoder, encoders differ, and the same picture can come out as differently compressed bytes. A seed reproduces the wallpaper, not necessarily the file. If you need the identical file again, keep the file.

What never leaves this browser

The generators — maker, matching pairs, gallery — compute everything inside the page. The input is a recipe, the output is a PNG your browser encodes itself, and the download travels from your browser's memory to your own storage without touching a network. There is no server-side renderer, because there is nothing a server could add.

The two photo tools — the depth-effect checker and the icon-tint matcher — accept a photo through the file picker, draw it to a canvas on your device, and measure it there: resolution against the selected device, contrast behind a labeled band, dominant colors by median cut. The photo is never transmitted, the results are numbers on your screen, and closing the tab is the end of them. By a standing decision, neither photo page carries an ad slot at all, so no third-party script shares a page with your photo.

None of this depends on trusting copy. The site's security policy instructs your browser to refuse requests to any origin but this one, so an attempted upload would be blocked by your own browser; camera and microphone access are switched off site-wide in the same headers, because photo input rides the file picker and nothing here has any business with a live camera. There are no accounts to create and no analytics running — the site serves pages and does not watch you use them.

You can check all of it from outside our code. Open your browser's developer tools and watch the network tab while you generate a wallpaper or measure a photo: the page's own files arrive, and after that, nothing. Or load a tool, switch to airplane mode, and keep working — everything still runs, because there is nothing left to ask a server for.

What this site does not do

No AI generation. Every pixel is arithmetic from a seed. There is no model, no prompt, no training data, and consequently no way for an output to quietly echo something a model once ingested. The trade is honest: an engine this simple has a recognizable style, and variety comes from seeds and palettes rather than from imitation.

No Apple assets — or anyone else's. This site ships no wallpaper made by any phone maker, recreates none, and draws no lock screens, clocks, bezels, notches, or interface mockups. The checker draws plain labeled wireframe bands in this site's own styling, because "the clock sits in this band" is information, not artwork. Device names appear as factual references to the phones people own. Depth Paper is independent and has no connection to Apple, Google, or Samsung.

No uploads, no accounts, no analytics. Said in full above; it belongs on this list too because an absence is easy to break by accident. The site's automated tests assert it on every build — the security policy's exact shape, the missing analytics beacon, the ad-slot rules on the photo pages — so the absence is enforced, not remembered.

No stored images, no font files. There is not a single raster image or font file on this site: thumbnails are live renders, previews are canvases, type is your system's own. That keeps pages small, and it is also the enforcement trick — a site with no image assets cannot be quietly holding someone else's.

Where the claims stop

A seed reproduces the picture, not the file. Export the same seed in two different browsers and you will get the same wallpaper with, very possibly, different bytes — PNG encoders differ in how they compress identical pixels. If your workflow depends on checksums matching, the seed is not a substitute for keeping the file.

The device table can lag reality. It is a snapshot of published specifications as of its last commit, so a model announced this morning is not in it yet. And because an entry needs two independent published sources that agree, adding one is deliberately slower than copying the first number a search returns — when sources disagree, the entry waits. The custom size option is the honest gap-filler, and it reports its clamps rather than silently correcting your numbers.

Your phone has the last word on display. Perspective zoom, parallax, launcher cropping and panning, battery-saver downscaling: an exactly sized file removes the system's reason to rescale, and removes nothing else. Those behaviors are settings and policies on the phone, and no file can override them. The two size charts explain what each platform does and which settings matter.

Depth effect is the phone's own judgment. The lock-screen layering decision is made by the operating system's subject segmentation, running on the phone, using a model this site does not have — no website can run it. The checker measures the three things a file can actually be measured for: resolution, subject placement against the bands, and contrast behind the clock. A photo can pass all three and still be declined by the phone, and the checker's page says the same thing.

Color is delivered as values, not as an experience. The engine's promise ends at the RGB values in the PNG. Between that file and your eye sit the panel, its calibration, its brightness, and every feature that warms or dims the screen by schedule — the identical file can look visibly different on two phones side by side. Nothing on this page claims otherwise.

Your browser is not ours to promise about. A browser extension can read any page it has permission for, this one included, and no header this site sends reaches into it. The security policy governs what this site's pages may request; what your browser and its extensions do around the page is outside any site's control, ours included.

The demonstration is bounded, and so are the tests behind it. Two renders compared in one browser prove agreement in that browser, at that size, today; the cross-browser version of the claim is an argument from fixed-order arithmetic, not a measurement. The site's own test suite re-checks determinism, the device data, and chart sync on every build — but a test suite is our code checking our code. The network tab, the airplane-mode test, and a second browser on your own desk remain the checks that owe us nothing.

Frequently asked questions

Will the same seed give me the same wallpaper next year?
Yes. A seed here is the complete recipe: the same seed with the same palette, point count, and size reproduces the same wallpaper on any visit, because every pixel is computed by fixed arithmetic with no hidden state. That is a property of the engine, not a policy. One scope note — the picture is reproduced exactly, but the downloaded file's bytes can differ between browsers, because their PNG encoders differ.
Where do the device sizes come from?
From a device table compiled by hand, in which every entry was cross-checked against two independent published sources before it appeared — and those sources are recorded next to each device family inside the data file itself. The table is versioned: values change only through reviewed commits, never by fetching anyone's endpoint, and it is updated as new devices ship. Both size charts are generated from the same table, and an automated check fails the site's build if a chart and the data ever disagree.
Is anything I make or load here sent to a server?
No. Gradients are computed inside the page, and the two photo tools read your photo through the file picker and measure it on your device — there are no uploads, no accounts, and no analytics anywhere on this site. The site's security policy tells your browser to refuse requests to any other origin, so the claim is enforced by your browser rather than just stated, and you can watch it hold in your browser's network tab.
Does this site use AI to generate wallpapers?
No. Every wallpaper is arithmetic: seeded control points blended by inverse-distance interpolation, plus a seeded grain that prevents banding. There is no model, no prompt, no training data, and no image library — the gallery's entries are seeds rendered live, not stored pictures. That is why results are exactly reproducible, and why nothing here can quietly resemble anyone's photograph or artwork: the engine has never seen one.
Is Depth Paper affiliated with Apple, Google, or Samsung?
No. Device names on this site are factual references to the phones people own, used to label sizes and settings — nothing more. Depth Paper is independent and has no connection to Apple, Google, or Samsung; it ships none of their artwork, recreates none of their wallpapers, and draws no mockups of their hardware or software. Every image you can make here is an original render from the site's own engine and palettes.

Related