This is a black-box design analysis based on the public interface of BlurImage. It does not claim access to source code, private architecture, or performance benchmarks. The goal is to turn a familiar image-editing task into explicit states that a frontend team can reason about and test.
Define the input contract
The page exposes four ways to provide an image: file upload, paste, image URL, and a website tab. It lists JPEG, PNG, and WebP as supported formats. A robust client should normalize all four paths into one SourceImage state, while retaining the origin for error messages and auditability.
type SourceImage = {
kind: "upload" | "paste" | "url" | "website";
mime: "image/jpeg" | "image/png" | "image/webp";
width: number;
height: number;
};
Treat the type above as a proposal, not observed implementation. The important behavior is that a rejected source does not erase a previously loaded image.
Model the editing state
The public editor describes eight blur styles and two selection strategies: paint a region, or invert the brush to keep a subject sharp while blurring its background. That suggests a state machine rather than a single blurred: boolean flag.
type EditState = {
source: SourceImage | null;
style: "gaussian" | "motion" | "radial" | "pixelate" | "noise" | "other";
regions: Array<{ x: number; y: number; w: number; h: number }>;
invert: boolean;
status: "empty" | "ready" | "previewing" | "dirty" | "exported" | "error";
};
Test the user-visible transitions
Use a matrix, not a happy-path screenshot. Empty state should explain how to add an image. A loaded image should expose a preview without requiring export. Changing style should update the preview while preserving painted regions. Undo should remove the latest edit only. Clear should require a deliberate action if it would remove several regions.
| Transition | Expected invariant | Failure to watch |
|---|---|---|
| source → ready | dimensions are known | broken EXIF orientation |
| ready → dirty | original remains recoverable | accidental overwrite |
| dirty → exported | chosen format is honored | wrong extension or alpha loss |
| error → ready | input remains selectable | blank canvas after retry |
Verify privacy at the edges
Selective blur is only useful if the mask covers the entire sensitive area. Test text near a region boundary, small faces, high-contrast plates, and a screenshot with repeated identifiers. Review at 100% zoom and at the final display size. A client-side workflow can keep pixels in the browser, but it cannot judge consent, legal requirements, or whether an indirect clue still identifies someone.
Keep export honest
The public page promises PNG, JPG, and WebP download and says processing happens in the browser. A test plan should verify MIME type, filename, dimensions, and whether transparency survives PNG export. It should also confirm that a failed export leaves the editable state intact. These checks are more valuable than an invented speed target.
Make privacy review a separate gate
Do not infer “safe” from a successful render. Add a review step that asks a person to inspect every region at native resolution, then at the channel’s display size. The reviewer should check contextual clues such as reflections, browser tabs, and repeated identifiers. If the image is for a regulated workflow, record the policy or owner that approved the redaction. This gate belongs next to export because it protects against a technically valid but socially unsafe artifact.
Checklist for implementation reviews
Ask whether every input path reaches the same validation logic, whether keyboard users can operate the brush controls, whether progress and errors are announced in text, and whether the preview is clearly distinguished from the original. The browser-only approach reduces upload risk, but memory pressure on very large files remains a practical boundary.
The Blur Image Online page is a useful reference point for this contract: it keeps the edit in the browser and exposes format-aware download choices.
The transferable lesson is simple: image blur is not one filter call. It is a sequence of source validation, region selection, reversible preview, and format-aware export. Making those states explicit gives a team something it can test, document, and improve.
Top comments (0)