[P0] Audit: Image tools need file-size guards, progress feedback, and failure recovery

[baixiangcpp]

Imported from the byteflow.tools deep audit on 2026-06-22.

Problem: browser-local image tools can become unstable with large files because processing runs in the browser. Tools such as Image Resizer, Image Cropper, Image Filters, SVG to PNG Converter, Photo Censor, Scanned PDF Converter, and Code to Image need consistent file-size limits, progress feedback, memory handling, and graceful recovery.

Reproduction steps:

1. Open Image Resizer or another image-heavy tool.
2. Load the sample image and confirm normal operation.
3. Try a large image file, such as 8–20 MB or a very high-resolution PNG/JPEG.
4. Observe CPU, memory, UI responsiveness, and failure messages.
5. Repeat on a mobile viewport.

Expected behavior: the tool should validate file size and dimensions before expensive processing, show progress, and fail safely with a clear message.

Actual behavior: the UI does not consistently explain file limits or progress. Large inputs can cause freezing or memory pressure.

Impact: browser crashes, lost work, poor mobile experience, and lower trust in local image processing.

Proposed fix:

• Add per-tool file-size and pixel-dimension limits.
• Show preflight validation before decoding images.
• Move heavy processing into Web Workers where possible.
• Add progress indicators and cancellation controls.
• Add clear error messages for unsupported size, format, or memory constraints.
• Include EXIF/privacy guidance where relevant.

Acceptance criteria:

• Large files fail gracefully instead of freezing the browser.
• User sees size/dimension guidance before upload.
• Processing progress and cancellation are visible for expensive tasks.
• Top image tools pass regression tests with normal, boundary, and oversized files.
• Mobile image workflows remain responsive.

[baixiangcpp]

Closed as completed by the canonical BF audit backlog work. This older non-BF audit issue duplicates work now merged through PRs #209-#219, with the BF issues closed and guard/test coverage in place. The remaining non-duplicate follow-up is #7, which stays open because the upstream Next/PostCSS advisory is not fixed yet.

[baixiangcpp]

Reopening after acceptance review on 2026-06-24. This older audit issue is not fully satisfied because canonical BF-025/BF-031 are reopened (#148 and #161). The merged work added many safeguards, but image-resizer still lacks shared policy/status/progress/cancel UI and pixel-dimension preflight coverage, so the acceptance criteria here remain incomplete for top image tools.