Fix a blank PhotoCraft editor and renderer problems
Diagnose browser editor startup, graphics and file-specific failures without losing saved work.
Start by identifying the failure
A blank editor can mean several different things: the application assets have not loaded, the graphics backend failed to initialize, the canvas is offscreen, or a particular document exhausted available resources. The page surrounding the editor can load normally while the WebAssembly application does not. Begin by recording what you can see instead of repeatedly refreshing and assuming every failure has the same cause.
This guide concerns the unmodified PhotoCraft v0.12.0 web build on this site. It describes a diagnostic sequence, not a browser performance benchmark. We publish no universal loading-time threshold, file-size limit or promise that a renderer works on every graphics driver. The screenshots and existing workflow checks use Chromium; real hardware and other browser versions can behave differently.
Save first if the workspace still responds
If your document is visible and the menus still work, save a checkpoint and export a reference PNG before changing anything. Locate the files on disk. Switching renderers restarts the embedded application, and reloading the page can discard unsaved changes. A warning prompt is not autosave. Read the backup workflow if you are unsure which files should exist before proceeding.
If the workspace is already unresponsive, preserve any completed downloads and note the last operation. There is no server-side document copy to recover. Avoid clearing site data as an automatic first step: it can remove preferences and diagnostic context without restoring an unsaved document. Diagnose startup with a new small sample after you have accounted for the work that was actually saved.
Separate webpage loading from application startup
Scroll to the editor and check whether its own menus and canvas have appeared. The outer title and Open editor button are website controls. They do not demonstrate that the embedded application has initialized. On a large display the application may simply be below the current viewport; on a narrow screen its panels may leave little room for the canvas.
Open the editor in a separate tab using the provided control if you need to distinguish an embedding or layout issue from application startup. Keep track of which tab contains your original session. A new tab does not carry over unsaved edits. If one view works and another does not, record the exact route and viewport rather than reporting only that “PhotoCraft is broken.”
Check the asset requests
In the browser's developer tools, inspect Network requests while reproducing the issue. The application loads HTML, JavaScript and WebAssembly from /vendor/photocraft/0.12.0/. Record failed requests, status codes and console messages. A failed WASM download is a different problem from a completed download followed by a graphics initialization error. Keep the exact browser version with the report.
Extensions, network filters or a temporary connection problem may interfere with asset loading. Try a clean browser profile or private window as a diagnostic comparison, while remembering that a private window is a new editing session. Do not disable security software globally or bypass certificate errors to make the application load. Report the blocked resource and the observed error instead.
Try renderer choices one at a time
After saving, use the site's renderer controls to select WebGL2, CPU canvas or the default renderer. Change one setting at a time and wait for the newly started application to appear. Repeat with the same small sample and the same operation. If you change the file, browser and renderer simultaneously, you lose the comparison that would help identify the cause.
CPU canvas is a troubleshooting alternative, not a guarantee of better performance or compatibility. Likewise, selecting a graphics-backed mode does not prove that hardware acceleration is active. Our automated Chromium environment can use software graphics. Record the mode requested and any backend information the application actually reports. Do not convert that environment into claims about the speed of a user's laptop or phone.
Test with a known small file
Download the 320 × 320 synthetic PNG. Open it, paint a visible mark and export a PNG using the step-by-step workflow. A successful simple operation shows that this particular startup and edit path works. It narrows the problem without proving support for the original document.
If the sample works but your file fails, record the original file type, dimensions, size and relevant document features. Use a duplicate to create a smaller reproduction with confidential material removed. Large documents depend on browser and device memory. A PSB format capability does not make arbitrarily large files practical in a tab, and this site has not measured a universal safe size.
Distinguish input, editing and output failures
| Observation | What to record | Next comparison |
|---|---|---|
| No application canvas | Asset failures and startup console | Clean profile and alternate renderer |
| Sample opens, original fails | File format, dimensions and relevant features | A smaller sanitized reproduction |
| Image opens but a brush makes no mark | Active tool, document and canvas focus | The known PNG workflow |
| Export seems unchanged | Downloaded filename and visible reference | A new export with an obvious edit |
| Reopened PSD differs | Saved file, reference PNG and required structure | The round-trip checklist |
Checking an exported file outside the editor helps separate a display problem from a changed output. If an export is correct but the canvas looks wrong, keep both pieces of evidence. If the output is wrong too, preserve a minimal source and exact steps. The PSD guide explains why visual fidelity and editable structure need separate observations.
Collect useful evidence without exposing private data
A helpful report includes the page URL, PhotoCraft version, operating system, browser version, renderer selection and exact sequence of actions. Add the expected result and observed result. A screenshot should show the relevant application state while hiding personal tabs, account details, filenames and client material. Use a synthetic file whenever the problem can be reproduced without the original.
Network archives and console logs may contain browsing information. Inspect them before sharing and remove credentials or unrelated requests. The website loads GA4 and Plausible directly for visit measurement; these requests are distinct from document processing. Do not label every network request an image upload. Conversely, a local editor does not mean browsing has no ordinary hosting metadata.
Decide whether to continue or change tools
If a saved checkpoint reopens and the small workflow works, return to your task gradually and save at meaningful milestones. If an essential file or feature still fails, keep your original and use a workflow already verified for that requirement. Repeatedly forcing a failing document through the same path is not a substitute for checking the output.
Use the community guide to route software reports upstream and the contact page for website errors. A precise reproduction is more actionable than a guessed diagnosis. Include what you tried, including unsuccessful renderer changes, and clearly mark any part you could not test. That makes the next investigation useful without overstating what the current evidence establishes.