Show HN: An API that takes a URL and returns a file with browser screenshots

Original Article ↗ Hacker News Discussion ↗

Use cases and overall reception

  • Many commenters find an HTTP API for browser-based screenshots useful for link previews, self-hosted bookmarking, visual regression, archiving, IoT displays, and privacy-preserving tweet embeds.
  • Several people say they’ve built similar internal tools and like having a generic “preview” microservice.

Cookie banners and EU consent dialogs

  • Cookie popups are described as the hardest practical problem for automated screenshots.
  • Approaches suggested:
    • Browser extensions like consent-o-matic to auto-accept/close banners.
    • Heuristics over DOM (common classes, “accept” strings, fixed/sticky + high z-index).
    • Vision models to detect banners and return coordinates to hide them, though cost and risk of removing real content are concerns.
    • SeleniumBase / CDP-based automation to search for consent text and click accept.
  • Some argue providers should simply stop “malicious compliance” with EU rules, others just want screenshots without banners regardless of compliance nuance.

Alternatives and tooling tips

  • Multiple alternatives are mentioned: Puppeteer, Playwright, Selenium, shot-scraper, gowitness, and prior open-source screenshot libraries.
  • Chrome and Firefox CLI flags for headless screenshots are highlighted; people appreciate not needing full Selenium stacks.
  • There’s discussion of Chrome’s deprecated --disable-gpu flag and differences in how Chrome vs Firefox handle full-page screenshots and scrolling artifacts.
  • Some suggest MCP as the preferred modern interface for exposing such tools to LLMs.

Hosted services vs self-hosting

  • Numerous commercial APIs are cited (screenshot, scraping, and browser-automation specialists).
  • Arguments for SaaS: avoiding scaling, CAPTCHAs/anti-bot countermeasures, long-term maintenance, and SSRF risk.
  • One provider’s automatic “upgrade to next pricing tier when over quota” policy is debated; some see it as customer-friendly continuity, others as an unacceptable unilateral charge.

Security considerations

  • Strong warnings about SSRF: untrusted URLs can let the headless browser hit internal services (e.g., Kubernetes API).
  • Recommended mitigations: Linux network namespaces, blocking private IP ranges, or routing via an isolated VPN.
  • This is cited as a major reason larger orgs avoid rolling their own.

Branding, features, and limitations

  • The us.ai domain and government-adjacent branding draw skepticism; some say it looks like a US government/defense contractor site.
  • Suggestions for the project: additional formats beyond JPEG, clickmap + link metadata, content diffing over time, better repo screenshots, and Cloudflare/anti-bot handling.
  • One commenter asks why this sits in an “artificial intelligence” repo when it’s mainly browser automation.