Coloring Page Maker: Save Your Work Before You Refresh

What we actually checked

We ran four full-reload checks in Chromium on October 18, 2026: two workflows at 390-pixel phone width and again at 1440-pixel desktop width. Each width started in a fresh browser context. These are browser viewport checks, not tests on two physical devices. We kept the site's production conversion and painting code unchanged.

For the Photo Maker, we selected a local copy of the site's baseball sample illustration through its file chooser. Using a local file let us distinguish an actual selected upload from the default demonstration image. We generated the coloring page with the default settings, waited for the download actions, and saved its PNG before issuing a full reload.

Before reload, both the selected-file panel and generated-result download actions were visible. After reload, both were hidden in each run. The sample demonstration could still be shown on the page; its presence did not mean the uploaded file or generated result had returned. The downloaded PNG was 1,834,898 bytes in both runs and retained the same SHA-256 hash after the page reloaded.

For Color Online, we opened the completed Big Petal Flower Mandala from the gallery, chose Brush, and painted at the center with the default red color. We measured the paint-layer pixel at that position. Its alpha channel was 255 before reload, meaning that the paint pixel was opaque. We saved the merged colored PNG, then reloaded the same editor URL and waited for it to finish loading.

After reload, the paint-layer alpha at that position was 0 in both viewport sizes, and Undo was disabled. The original black-and-white outline loaded again, but the added paint and the earlier action history did not. The saved colored PNG was 102,138 bytes in both runs and its hash remained unchanged. The measurement reads the transparent paint layer, not the black-and-white outline layer or the white background added during export.

This distinction explains why a file can survive while the editing session does not. Reloading the page resets the tool's in-memory state; it does not erase the PNG file already saved by the browser in this check. We verified the downloaded file separately instead of treating a successful download-button click as proof that a usable file existed.

The test covers a full page reload in the recorded Chromium environment. We did not test every browser, a phone operating system terminating a tab, Back/Forward cache behavior, device storage failures, or cloud backup services. Do not rely on another browser keeping a tab alive as an autosave feature. The implementation currently exposes file downloads, not an editable-project restore workflow.

Read the four recorded results and method. To repeat the check, use an image you can afford to reload, generate or paint a result, save its PNG, confirm the downloaded file, then reload. Avoid testing with work you have not saved.