PhotoCraft community, Reddit research and GitHub issues

Start at the repository

GitHub issues and discussions linked by the upstream README are the most direct places to investigate bugs or planned changes. The README also links the ArtCraft Discord. This site does not operate an official support channel or guarantee a response from maintainers.

Reading PhotoCraft Reddit posts

Search for the exact repository name storytold/photocraft together with Reddit. Check the post date, release tag, linked repository and whether the writer actually tested a file. A comment about an unrelated PhotoCraft Studio, a different app or an old build is not evidence about this editor.

Report a reproducible issue

Record your browser, platform and the pinned editor version. Explain the steps and expected result. If a file contains private material, do not attach it publicly; create a small non-sensitive example if possible. The editor page offers renderer troubleshooting before you report a loading issue.

Choose the channel by responsibility

The upstream PhotoCraft contributors develop the editing application. The photocraft.tools maintainer hosts this fixed browser release and publishes the surrounding guides. A broken website link, translation error or privacy question belongs with the website maintainer. A reproducible defect inside the editor can require an upstream issue. The same distinction applies even when you first notice the defect while reading this website.

Use the contact page for website feedback and check the official repository before choosing a project discussion or issue channel. A same-name application can have a different publisher and support process. Do not assume a search result or store listing belongs to the ArtCraft project. The project identity guide explains the source links this website uses.

Check existing reports without hiding a new result

Search the upstream issue list using a concise description of the observed operation, the relevant format and the version. Read the context of a similar report before concluding it is the same problem. A fix on a development branch may not exist in the pinned v0.12.0 browser package, and a newer native release may use a different environment.

If you add information to an existing report, state your exact version and reproduction. Avoid claiming that every user is affected from a single observation. If the issue cannot be reproduced with a public sample, explain what is known and what is missing. A useful contribution can be a narrower failure case or a clear correction, not only a proposed code change.

Build a minimal reproduction

Start with an untouched copy and reduce the input until it demonstrates the problem without unrelated content. Prefer a synthetic image or a newly created document. Record the sequence from opening the file to the first unexpected result. Change one condition at a time so you can explain whether the browser, renderer or document feature affected the outcome.

For a save/reopen problem, keep the source, saved file and reference export separately. A report that only contains the final broken file may not show which operation introduced the difference. The PSD guide explains why appearance and editable structure are separate observations. Identify which failed instead of describing every mismatch as a completely unreadable file.

Include an actionable report

Write the page or application source, PhotoCraft version, operating system, browser version where relevant, selected renderer, input dimensions and exact steps. Then describe expected behavior and observed behavior. State whether the issue also occurs with the site's known small PNG workflow. Include the first meaningful error message rather than an unfiltered wall of logs.

A short example report might say: open the synthetic PNG in the pinned browser build, paint one visible mark, save a new PSD, reopen it and export a PNG; the second export differs in the marked region. That sequence lets someone repeat the observation. Do not write that example as your actual result unless it is what you measured.

Protect private material before sharing

Public issue trackers and community chats are not private storage. Check file contents, metadata, filenames, screenshot tabs and console logs before posting. Remove client artwork, contact details, access tokens and internal paths where possible. You need permission to share a third party's document even if the technical problem is genuine.

An image that looks anonymous can still carry identifying context in its filename or metadata. A network archive can contain unrelated browsing information. Prefer the smallest synthetic reproduction that demonstrates the issue. If the problem requires confidential data, ask the responsible project about an appropriate process before sending it, rather than uploading it publicly and requesting deletion afterward.

Set expectations for support and contributions

This independent site does not promise a fixed support response time or act as the upstream project's release manager. A report is not a guarantee of a fix in a particular release. Keep originals, saved checkpoints and an alternative workflow for important work while an issue is investigated. The browser build has no server-side document recovery service.

Before submitting a code change upstream, read that project's current contribution instructions and license requirements. Before suggesting a guide correction here, identify the exact page and language. Do not invent a successful test, claim a credential you do not have or present an AI-generated explanation as measured evidence. Clear uncertainty is more useful than false confidence.

Keep discussions useful and attributable

Stay focused on the reproducible problem, avoid personal attacks and do not post spam or unrelated promotion. Credit relevant sources and previous reports. A clarification that separates a browser focus conflict from an application command failure can save more investigation time than a broad complaint without steps.

This website currently has no public comments, forum or submission publishing feature. Sending feedback by email does not authorize publication of your message or attachments. If we later add public contributions, they will need moderation and rights handling before launch. For now, use the established upstream channels for project discussion and the maintainer contact for website-specific corrections.