It produces six kinds of frontend output from visual input
Screenshot to Code accepts screenshots, mockups, Figma designs, and screen recordings, then asks a model to produce a working interface. The README lists 6 output choices: HTML with Tailwind, HTML with CSS, React with Tailwind, Vue with Tailwind, Bootstrap, and Ionic with Tailwind. That breadth makes it useful for creating a first implementation when the visual target already exists and writing the opening markup by hand would add little value.
The useful word is first. A screenshot records pixels, not heading levels, focus order, data rules, breakpoints, or what happens after a click. A generated page can look close while still having the wrong semantics or brittle layout code. Treat the result as a draft that a frontend developer owns. The project saves reconstruction time; it does not replace accessibility review, responsive testing, or the decisions hidden behind the captured screen.
Four provider keys split the feature set
Local use requires at least 1 model provider key from OpenAI, Anthropic, or Gemini. The frontend settings can hold those three. Replicate is configured in the backend environment file. With one provider, the app limits itself to models from that provider; adding more keys lets it generate and compare variants. This is practical for evaluation, though every extra provider adds another billing account and another place where visual input may be processed.
Capabilities are divided by provider. The README says Gemini handles asset extraction and is required for turning a screen recording into a prototype. Replicate supplies image generation, editing, background removal, and related tools. Without Replicate, image editing and background removal are unavailable. A team choosing the project for one of those features should map the required provider before deployment instead of assuming any supported code model unlocks the whole interface.
What happened when we ran it
Our sandbox installed commit d026163 in 139 seconds. The install added 804 packages and occupied 344 MB on disk. The repository had 315 files and about 39,986 source lines in a 2.7 MB checkout. There was no build script or target, so we skipped the build rather than substituting a command that the project does not define.
The test command ran for 10 seconds and exited with code 1. Jest reported 42 passed tests, 0 failed, and 6 skipped out of 48. After that successful frontend portion, the root command entered the backend and tried poetry run pytest; the shell returned poetry: not found. The log shows a missing executable in our fresh container. It does not show whether the Python suite itself passes once Poetry and its dependencies are installed.
Npm audit reported 16 known vulnerabilities: 1 critical, 11 high, and 4 moderate. That result belongs to the installed dependency tree in our stated sandbox, not a claim that the application is exploitable. Still, 12 critical or high findings are enough to require triage before putting an upload service on a public network. Our scan also found 0 CI workflow files and no Dockerfile, although the repository does include a Compose file.
The documented local route has two runtimes and Chromium
The manual setup runs a FastAPI backend on port 7001 and a React and Vite frontend on port 5173. Backend setup uses Poetry. The optional screenshot preview tool needs Playwright and Chromium so the agent can render its output and inspect it. On Linux, the documented command for Chromium's system libraries uses sudo or apt, an extra host-level step that a plain JavaScript install does not cover.
Docker Compose reduces the number of commands and starts the app at port 5173, but the README warns that it is unsuitable for live development because source changes do not trigger a rebuild. There is no Dockerfile at the repository root according to our scan, so operators should inspect how the Compose build context is arranged before adapting it. A custom backend port also requires matching HTTP and WebSocket addresses in the frontend environment file.
Local models trade provider privacy for lower expected quality
The README links an Ollama route for open-source models and explicitly describes its results as poor quality. That option may keep more of the workflow under your control, but it changes the central promise: close visual reconstruction depends heavily on the model interpreting the screenshot. Teams with a strict no-cloud policy should test the exact pages they care about before investing in the surrounding app.
Cloud use creates a different review. Screenshots can contain unreleased product UI, customer records, names, or internal dashboards. The project needs those pixels for generation, asset work, or video analysis, and the chosen provider's handling terms become part of the deployment decision. Redaction before upload is sensible for sensitive material, though it can remove the visual details the tool is supposed to reproduce.
August activity is current, while releases are absent
GitHub recorded the last push on August 14, 2026. The repository had 75,259 stars and 130 combined open issues and pull requests when fetched; a separate search split that queue into 121 issues and 9 pull requests. Recent August entries include a request for account-free preview links and proposed Docker fixes. The queue is active, but its size means users should search existing reports before opening another setup question.
The latest-release endpoint returned 404, so there is no current GitHub release to use as a deployment anchor. Pinning a commit is the safer choice for a self-hosted install. Screenshot to Code earns a trial when the input is visual and the output will be edited by someone who understands the target stack. The 344 MB dependency footprint is manageable; the failed full test command, 16 audit findings, provider split, and absent release tags make unattended adoption hard to recommend.