Screenshot to Code: vom Bild zum Frontend, und was die Schlüssel freischalten

Was screenshot-to-code aus einem Bild macht: sechs Stacks, ein FastAPI-Backend

Screenshot to Code nimmt einen Screenshot, ein Mockup, ein Figma-Design oder eine Bildschirmaufnahme und gibt frontendfähigen Code aus. Die README nennt sechs Ziel-Stacks: HTML mit Tailwind, HTML mit CSS, React mit Tailwind, Vue mit Tailwind, Bootstrap sowie Ionic mit Tailwind. Geschrieben ist das Repository in Python, und die Anwendung besteht aus einem React/Vite-Frontend mit einem FastAPI-Backend. Wer nichts einrichten will, findet unter screenshottocode.com eine gehostete Fassung, auf die die README ausdrücklich verweist.

An den Repositoriumsdaten lässt sich das Gewicht ablesen: über 75.000 Sterne und rund 9.200 Forks. Gleichzeitig stehen 131 offene Issues offen. Der Videomodus ist der jüngere Teil des Projekts, bei dem eine Aufnahme einer Website in Aktion in einen funktionsfähigen Prototyp übergehen soll.

Modellbelegung in screenshot-to-code und ein Widerspruch in der README

Bei der Modellauswahl setzt die README auf eine Mischung mehrerer Anbieter. Als Standardmodelle werden Gemini 3 Flash Preview und Gemini 3.1 Pro Preview genannt und als beste Modelle bezeichnet, dazu GPT-5.5 und GPT-5.4 Mini sowie Claude Opus 4.6 und Claude Opus 4.8. Für die Bilderzeugung kommt z-image-turbo über Replicate hinzu.

An dieser Stelle lohnt ein genauer Blick, denn die Angaben sind in sich nicht konsistent. Während die Aufzählung bei Anthropic von Opus 4.6 und Opus 4.8 spricht, nennt die Tabelle zu den Schlüsseln Opus 5, Opus 4.8, Fable 5 und Sonnet 4.6. Wer wissen will, welches Modell tatsächlich angesprochen wird, kommt an einem Blick in den Quellcode nicht vorbei, die README klärt den Widerspruch nicht.

Die Einstufung von Gemini 3.1 Pro als bestem Modell ist eine Einschätzung des Projekts, keine Messung. Benchmarks oder Trefferquoten fehlen, sodass sich die Qualitätsaussage nicht nachprüfen lässt.

API-Schlüssel als Funktionsschalter in der .env-Datei

Der Funktionsumfang hängt unmittelbar an den hinterlegten Schlüsseln. Zwingend ist mindestens einer von dreien: OPENAI_API_KEY, ANTHROPIC_API_KEY oder GEMINI_API_KEY. Mit nur einem Schlüssel nutzt die Anwendung laut README ausschließlich die Modelle dieses Anbieters. Liegen mehrere vor, wählt sie pro Variante automatisch eine stärkere Mischung, und die Ergebnisse lassen sich anbieterübergreifend vergleichen.

Zwei Schlüssel werden ausdrücklich empfohlen, weil sie eigene Fähigkeiten öffnen. GEMINI_API_KEY übernimmt die Asset-Extraktion, bei der echte Logos und Bilder aus dem Screenshot wiederverwendet werden, und ist Voraussetzung für den Videomodus. REPLICATE_API_KEY schaltet Bilderzeugung, Hintergrundentfernung und Bildbearbeitung frei; ohne ihn bleiben die Funktionen edit_images und remove_backgrounds unerreichbar. Wer nur einen OpenAI-Schlüssel hinterlegt, erhält Codegenerierung über GPT-5.5 und GPT-5.4 Mini und nichts darüber hinaus.

Ollama lässt sich laut README ebenfalls anbinden. Das Projekt rät davon ab, weil die Ergebnisse schwach seien, und verweist auf einen Kommentar in Issue 354.

Lokaler Aufbau mit Poetry, Playwright und pnpm dev auf Port 5173

Der lokale Weg beginnt im Verzeichnis backend. Die Schlüssel werden in eine .env-Datei geschrieben, danach folgen poetry install, poetry run playwright install chromium, das Aktivieren der Umgebung über poetry env activate und schließlich poetry run uvicorn main:app --reload --port 7001. Unter Linux empfiehlt die README zusätzlich poetry run playwright install --with-deps chromium, weil sonst Systembibliotheken fehlen; dieser Schritt verlangt sudo und apt.

Im Frontend genügen pnpm install und pnpm dev. Erreichbar ist die Anwendung anschließend unter http://localhost:5173. Läuft das Backend auf einem abweichenden Port, wird VITE_WS_BACKEND_URL in frontend/.env.local angepasst. Für getrennte HTTP- und WebSocket-Ziele nennt die FAQ zusätzlich VITE_HTTP_BACKEND_URL, als Beispielwert wird http://124.10.20.1:7001 angegeben.

OpenAI-, Anthropic- und Gemini-Schlüssel lassen sich alternativ über den Einstellungsdialog im Frontend setzen, zu erreichen über das Zahnradsymbol nach dem Laden der Anwendung. REPLICATE_API_KEY muss dagegen in backend/.env stehen. Wer keinen direkten Zugang zur OpenAI-Schnittstelle hat, setzt OPENAI_BASE_URL, wobei der Pfad ein v1 enthalten muss.

Docker-Start per docker-compose und wo dieses Setup endet

Mit Docker verkürzt sich der Start auf zwei Zeilen im Wurzelverzeichnis: echo "OPENAI_API_KEY=sk-your-key" > .env und docker-compose up -d --build. Die Anwendung läuft danach unter http://localhost:5173. Chromium ist im Image bereits vorhanden, der Playwright-Schritt entfällt.

Die README benennt die Grenze selbst: Für die Entwicklung taugt dieser Aufbau nicht, weil Dateiänderungen keinen Neuaufbau auslösen. Wer am Code arbeitet, braucht den Poetry-Weg mit --reload. Auf Windows wird zudem auf ein UTF-8-Problem mit der .env-Datei hingewiesen, das sich über Notepad++ und die Codierung UTF-8 beheben lässt.

Screenshot-Vorschau: der Agent prüft die eigene Seite in Chromium

Die interessanteste Funktion ist die Screenshot-Vorschau. Sie erlaubt dem Agenten, die selbst erzeugte Seite in einem Headless-Browser zu rendern und das Ergebnis visuell zu kontrollieren. Aktiviert wird sie automatisch, sobald Chromium installiert ist; fehlt es, überspringt die Anwendung das Werkzeug. Der Einstellungsdialog zeigt an, ob die Vorschau zur Verfügung steht.

Damit verschiebt sich die Arbeitsweise vom einmaligen Durchlauf zu einer Schleife: erzeugen, rendern, vergleichen, nachbessern. Wie oft diese Schleife durchlaufen wird und woran der Agent einen Fehler erkennt, steht in der README nicht. Die gezeigten Beispiele, Nachbildungen von NYTimes, Instagram und Hacker News, dienen der Demonstration, nicht der Bewertung von Treffsicherheit.

Genau hier liegt der Unterschied zu einem reinen Konverter: Ohne Chromium bleibt das Werkzeug ein Einweg-Generator, mit Chromium wird daraus ein Prozess mit Rückkopplung.

Keine Releases, keine Version, aber MIT von 2023

Zur Versionierung gibt das Repository wenig her: Es sind keine Releases hinterlegt, und ein Veröffentlichungsdatum ist in den Metadaten nicht angegeben. Wer screenshot-to-code in einer Pipeline festschreiben will, muss einen Commit oder ein Datum notieren. Für Rückfragen verweist die README auf Troubleshooting.md sowie auf Kommentare in den Issues 3 und 354.

Lizenziert ist das Projekt unter MIT, Copyright 2023 Abi Raja. Die Erlaubnis deckt Nutzung, Kopie, Änderung, Veröffentlichung, Vertrieb und Unterlizenzierung ab, solange der Copyright-Vermerk mitgeführt wird. Gewährleistung und Haftung sind ausgeschlossen. Support, Sicherheitszusagen oder eine Aussage zur Produktionsreife enthält der Lizenztext nicht, und die README ergänzt dazu nichts.

Redaktionelles Fazit

Screenshot to Code passt zu Entwicklern, die einen Entwurf zügig in lauffähiges HTML, React oder Vue überführen wollen und dafür API-Schlüssel hinterlegen können. Ungeeignet ist es für Umgebungen ohne Zugang zu externen Modell-Endpunkten, der Weg über Ollama wird von der README selbst als qualitativ schwach bezeichnet. Wer nur gelegentlich einen Entwurf umsetzt, fährt mit der gehosteten Fassung unter screenshottocode.com besser. Vor dem Selbsthosting sollte geklärt sein, ob GEMINI_API_KEY und REPLICATE_API_KEY vorhanden sind, sonst fehlen Asset-Extraktion, Videomodus und Bildbearbeitung; danach genügt ein Docker-Start auf Port 5173 mit einem einzigen Screenshot.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository