Image and video decision
X to Image
A single competent developer can build and run a useful replacement (URL parsing, fetch, render to WEBP, storage, UI); nothing on the site indicates durable moats that prevent reimplementation.
Visit website↗Built by Ozgur Ozer, who ships 12 products in this index
Not priced
No pricing page we fetched carried a figure, so there is nothing to compare against. The build side is still real.
$50one-off24 h to build
$10/mo3 h/mo upkeep
No published price to break even against.
No open-source build does this yet
Nothing published replaces this one, so a replacement starts from an empty file. Here is what it would have to cover.
What a replacement has to do
- User pastes a public X post URL → service fetches post content → render a clean screenshot image → store and serve downloadable WEBP
What it still won’t have
- Hosted public gallery and reuse of previously-generated screenshots (unless you build and operate it)
- The project’s existing domain, branding, and any organic traffic that brings users
- Potential optimizations and hardening for large-scale anonymous traffic
What remains hard
- Product polish and ongoing maintenance
First-year cost
No published price
X to Image does not publish a price we could read, so there is nothing to compare against. What building costs is below.
Money you would actually spend
Time you would spend
—
What you would spend
What we assumed
The verdict above measures whether you could build it. This one is only about money.
Runnable build prompt
Build a small web service in Node.js (Express) + React frontend that converts public X post URLs into downloadable WEBP screenshots. Stack: Node.js, Express, Puppeteer for HTML rendering, PostgreSQL (or SQLite) for minimal metadata, and S3-compatible storage (e.g., AWS S3) behind a CDN (CloudFront). Core features in scope: (1) frontend with a paste box and preview + download button, (2) URL validation and post-ID extraction, (3) server-side fetch of public post content and media with retries and rate-limit handling, (4) render standardized HTML/CSS of the post and capture to WEBP via Puppeteer, (5) store image and metadata, return permanent public URL and optional public gallery endpoint, (6) background worker queue for rendering, (7) basic logging, errors surfaced to user, and automated tests for URL parsing, rendering pipeline, and storage. Out of scope: reproducing X’s exact proprietary UI or supporting private/protected posts. Require error handling for fetch/render/storage failures and unit + integration tests covering the rendering pipeline and API endpoints.
How we checked
How the score was reached
- Build verdict base78
- 3/3 assessment runs agreed+4
- Evidence score82
The base comes from the verdict. Everything under it is a check that either happened or did not, and each one is a fact frozen in this record rather than a judgement made at render time - so the same evidence always produces the same number.
How scoring works →Cited sources · 1
Every page the run actually retrieved.
- official productX to Image — homepage and FAQ
Integrity checks
What held up, and what did not.
