screenshotrun vs Microlink: Screenshot API Comparison for Developers

Microlink handles over 100 million API requests per month. It powers metadata extraction, link previews, PDF generation, and screenshots for thousands of developers. The project is open-source at its core, well-documented, and has a JavaScript SDK that works in Node, browsers, and Deno. Anyone looking for a URL-to-data API with broad capabilities should consider it seriously.

But "does everything" and "does screenshots well" aren't the same claim. Developers searching for a microlink alternative usually arrive at that search after hitting a specific wall: limited screenshot parameters, PNG-and-JPEG-only output, or the realization that Microlink returns a JSON envelope with a CDN link instead of the actual image bytes. This comparison lays out where screenshotrun and Microlink differ on screenshot capabilities, pricing, and API design so the decision can rest on data rather than habit.

Transparency note: I built screenshotrun, so there's an inherent bias here. The comparison sticks to verifiable claims — pricing from public pages, features from documentation, limitations confirmed by testing both APIs.

screenshotrun vs Microlink: quick comparison

Two products built for different jobs. Microlink is a multi-tool: metadata extraction, technology detection, color palettes, screenshots, PDFs, all from one endpoint. screenshotrun does one thing — turns URLs, HTML, or Markdown into images and PDFs with the parameter depth that dedicated use requires.

The core difference: metadata API vs screenshot API

Send a GET request to api.microlink.io?url=https://example.com and you get JSON back: title, description, author, language, a detected image, the site's logo. Screenshots are opt-in. Add &screenshot=true and the response JSON gains a screenshot.url field pointing to an image on Microlink's CDN.

That architecture tells you where the engineering effort went. Microlink is excellent at extracting structured data from URLs. Screenshots are a feature, not the product.

With screenshotrun, hit the API and you get image bytes back. No JSON wrapper, no CDN hop, no second request to download the file. The response IS the screenshot. That also means one network roundtrip instead of two — parse JSON, then fetch the image from CDN adds measurable latency that a direct binary response simply doesn't have.

In practice: if you need to pipe a screenshot directly into S3, attach it to a Slack message, or embed it in a PDF report, a direct binary response saves the JSON-parse-and-download dance. If you need metadata alongside a screenshot, Microlink handles both in one call, but the screenshot you get back has fewer knobs to turn.

What happens when you need more than a basic capture?

Microlink gives you viewport dimensions, device emulation (dozens of presets, including desktop Macs), CSS/JS injection, a time-based wait, and adblock. That covers basic captures well. Having adblock on by default is a smart design choice. Most screenshots look cleaner without cookie banners and ad overlays. Though it can backfire: compliance teams screenshotting their own ad placements won't appreciate the ads being stripped automatically.

Where things get thin is beyond the basics. Microlink doesn't offer a documented full-page capture toggle. You get the viewport, not the entire scrollable page. No dark mode forcing for pages that support prefers-color-scheme: dark. No wait-for-selector — only time-based delays, which means if a page finishes loading in 800ms, you either wait the full 3 seconds you specified or risk capturing before a critical element renders. Selector-based waiting adapts to actual page behavior. That distinction alone saves hours of debugging on SPAs where hydration timing varies by deploy.

No click-before-capture for dismissing overlays or expanding accordions. No element hiding via CSS selectors without writing custom JS. No HTML or Markdown input. It's URL-only, so generating OG images from a template or converting a Markdown doc to PNG means hosting the HTML at a public URL first, then screenshotting that URL. screenshotrun accepts raw HTML and Markdown directly.

Only PNG and JPEG output. No WebP (typically 30-40% smaller files for the same quality), no AVIF, no TIFF. The CDN might auto-optimize delivery format, but you can't request a specific format from the API itself. No transparent backgrounds for compositing. No webhook delivery for async batch workflows.

None of these are defects. Microlink wasn't built to be a full screenshot toolkit. But a developer whose actual job is "capture screenshots at scale with precise control" will feel the gaps fast. I've seen teams work around the missing full-page toggle with JS injection that scrolls the page and stitches viewport captures together. It works. It's also fragile, and it shouldn't be necessary from a screenshot API.

Microlink pricing vs screenshotrun: different models, different math

Direct price comparison here is tricky because the products bundle differently. Microlink's request count covers ALL API calls (metadata lookups, screenshot captures, PDF generation) while screenshotrun counts only screenshot captures. A Microlink user calling the API for both metadata and screenshots burns quota on both.

Raw numbers look favorable for Microlink at first glance. $49 for 46,000 requests works out to roughly $1.07 per thousand. screenshotrun's $9 plan is $3 per thousand. But that comparison ignores what's actually being counted.

For a team that only needs screenshots, Microlink's $49 buys access to metadata extraction, technology detection, and color palette features they'll never touch. screenshotrun's $9 entry point means a developer who needs 2,000 screenshots per month pays $9, not $49. And screenshotrun offers four plan tiers between $9 and $99, so teams pay closer to their actual usage rather than jumping from free to $49 with nothing in between.

Under 10,000 screenshots per month, screenshotrun's plans are materially cheaper. Anyone comparing microlink pricing to dedicated screenshot API alternatives will notice this gap at low-to-mid volume. At high volume where Microlink's bundled pricing shines, the question becomes whether the team genuinely uses the full metadata+screenshot stack or just needs captures.

When Microlink is the better choice

Microlink makes more sense when the job is broader than screenshots:

• Metadata extraction: pulling title, description, author, images, and Open Graph tags from URLs. This is Microlink's core strength. screenshotrun doesn't do metadata at all.
• Link preview generation: building rich cards that show a page's title, description, and thumbnail in a single API call.
• Technology detection: identifying the tech stack behind a website. Niche, but useful for competitive analysis tools and sales intelligence platforms.
• High-volume mixed workloads where a pipeline already makes 30,000+ metadata calls per month and adds occasional screenshots. One API, one bill, less operational overhead.
• The JavaScript SDK is genuinely well-built. Works in Node, browsers, and Deno. If the team is JS-first and values SDK polish, Microlink delivers.

When screenshotrun is the better microlink alternative

screenshotrun fits better when the primary job is capturing screenshots with control:

• Screenshot parameter depth: full-page capture, wait-for-selector, click-before-capture, element hiding, dark mode, transparent backgrounds. Built for screenshot workflows, not added to a metadata API as a secondary feature.
• Direct image response: image bytes back from the API. No JSON parsing, no CDN fetch. Fewer moving parts in the pipeline.
• HTML and Markdown rendering: pass raw markup directly. OG images, email templates, documentation screenshots — no need to host HTML at a public URL first.
• Modern output formats: WebP and AVIF alongside PNG, JPEG, and PDF. A WebP screenshot is typically 30-40% smaller than PNG at equivalent quality. At scale, that's real bandwidth savings.
• Lower entry price for screenshot-only work. $9/month for 3,000 screenshots versus $49 for Microlink Pro. If you don't need metadata extraction, paying $49 for an API that happens to include screenshots is overpaying.
• AI agent integration via first-party MCP server for Claude, GPT, and other agents that need to "see" web pages.

Try both. Seriously.

If the current workflow already uses Microlink for metadata and screenshots, try routing just the screenshot calls to screenshotrun while keeping Microlink for metadata. Compare the output side by side. If the captures improve and the bill drops, the split makes sense. If the single-vendor simplicity of Microlink outweighs the savings, stay put. No comparison page can answer that for a specific codebase.

Run the same three URLs through both APIs. Compare capture time, file size, and whether full-page mode works on the target site. That tells more than this page ever could.

For teams using Microlink primarily for link previews, the link previews use case page shows how screenshotrun handles that workflow. The best screenshot API 2026 comparison covers the broader market. And if you're evaluating a microlink alternative alongside the self-hosting route, the Puppeteer vs screenshot API guide breaks down those tradeoffs.