DEV Community: Davis

3 ways to add link previews to a React app (with and without a backend)

Davis — Wed, 15 Jul 2026 13:05:55 +0000

Link previews (those little cards with a title, image, and description) make any list of URLs dramatically more scannable. But you can't build them purely client-side: fetching another site's HTML from the browser is blocked by CORS, and even if it weren't, you'd be shipping a full HTML parser to every visitor.

You need something server-side. Here are three ways to do it in a React app, from zero-backend to full DIY.

Option 1: Zero backend — call a metadata API from the client

If your app has no server (static SPA, GitHub Pages, etc.), use a metadata extraction API that supports CORS. I built LinkPeek for exactly this — it returns title, description, image, favicon, site name, OpenGraph and Twitter Card data as JSON.

import { useEffect, useState } from "react";

function LinkCard({ url }) {
  const [meta, setMeta] = useState(null);

  useEffect(() => {
    let alive = true;
    fetch(`https://linkpeek.dpears.workers.dev/v1/preview?url=${encodeURIComponent(url)}`)
      .then(r => r.json())
      .then(data => alive && setMeta(data))
      .catch(() => alive && setMeta({ error: true }));
    return () => { alive = false; };
  }, [url]);

  if (!meta) return <div className="link-card skeleton" />;
  if (meta.error || !meta.title) return <a href={url}>{url}</a>;

  return (
    <a href={url} className="link-card" target="_blank" rel="noopener noreferrer">
      {meta.image && <img src={meta.image} alt="" loading="lazy" />}
      <div>
        <strong>{meta.title}</strong>
        <p>{meta.description?.slice(0, 140)}</p>
        <small>
          {meta.favicon && <img src={meta.favicon} width="14" height="14" alt="" />}
          {meta.siteName ?? new URL(url).hostname}
        </small>
      </div>
    </a>
  );
}

With some card CSS (flex row, rounded corners, muted description text) this renders a Slack-style unfurl. The anonymous tier allows 25 requests a day per IP — enough for development. For production there's a free plan (500/month) and paid tiers via RapidAPI, plus a tiny typed client on npm:

npm i linkpeek-client

import { LinkPeek } from "linkpeek-client";
const lp = new LinkPeek({ rapidApiKey: process.env.RAPIDAPI_KEY });
const meta = await lp.preview("https://github.com");

Option 2: Next.js — fetch server-side, render static

If you're on Next.js, do the extraction at build/request time so the client ships zero fetch logic:

// app/components/LinkCard.jsx (Server Component)
export default async function LinkCard({ url }) {
  const res = await fetch(
    `https://linkpeek.dpears.workers.dev/v1/preview?url=${encodeURIComponent(url)}`,
    { next: { revalidate: 86400 } } // cache 24h
  );
  const meta = await res.json();
  // ...same JSX as above, no useState/useEffect needed
}

Server components + revalidate give you cached previews with no client waterfall — the card is in the initial HTML, which also means it works in RSS readers and with JS disabled.

Option 3: Full DIY

Rolling your own is a fun weekend project. The core is simple — fetch the page, parse <meta property="og:*"> tags — but production hardening is where the time goes:

Redirects & canonical URLs (short links, tracking wrappers)
Bot blocking — many big sites serve challenge pages to datacenter IPs
Relative URLs in og:image and favicons that need resolving
Fallback chains — og:title → twitter:title → <title>
SSRF protection — if you fetch user-supplied URLs, you MUST block localhost, RFC-1918 ranges, and internal hostnames, or your preview endpoint is a proxy into your own infrastructure
Caching — you do not want to re-fetch a URL on every render
Rate limiting — a public preview endpoint will be abused

I wrote up the sharpest edge I hit (distributed rate limiting on eventually-consistent storage) here, and the whole extractor is open source (MIT) if you want to read a working implementation: github.com/daviscodesbugs/linkpeek.

Which to pick?

Situation	Pick
Static site / SPA, no backend	Option 1 (client fetch)
Next.js / Remix / server rendering	Option 2 (server fetch + cache)
Learning project, or very high volume	Option 3 (DIY)

Questions welcome — happy to go deeper on any of these in the comments.

I built a link preview API on Cloudflare Workers — and learned KV is not a counter

Davis — Wed, 10 Jun 2026 15:34:50 +0000

I shipped a link preview API in a day on Cloudflare Workers — and the most interesting bug had nothing to do with HTML parsing.

What I built

LinkPeek does one thing: give it a URL, get back clean JSON with everything you need to render a link card — title, description, images, favicon, site name, canonical URL, RSS/Atom feeds, oEmbed endpoint, and the full OpenGraph + Twitter Card maps.

curl "https://linkpeek.dpears.workers.dev/v1/preview?url=https://github.com"

{
  "title": "GitHub · Change is constant. GitHub keeps you ahead.",
  "siteName": "GitHub",
  "image": "https://images.ctfassets.net/.../GH-Homepage-Universe-img.png",
  "favicon": "https://github.com/fluidicon.png",
  "og": { "site_name": "GitHub", "...": "..." },
  "twitter": { "card": "summary_large_image", "...": "..." }
}

There's also a tiny zero-dep client on npm: linkpeek-client.

Why Workers is a great fit for this

HTMLRewriter is the killer feature. Parsing arbitrary HTML on an edge function sounds expensive, but HTMLRewriter is a streaming parser — you register element handlers and it processes the response body as it flows through:

const rewriter = new HTMLRewriter()
  .on("meta", metaHandler)
  .on("title", { text(t) { titleText += t.text; } })
  .on("link", feedAndFaviconHandler);

I cap parsing at 1MB and cancel the stream after that — a page's metadata lives in <head>, so there's no reason to chew through a 20MB page.

KV as a response cache works great. 24h TTL, keyed by URL. Repeat lookups return in ~30ms globally.

The bug worth writing about: KV is not a counter

For the free tier I wanted a simple per-IP daily quota. First implementation: read a counter from KV, increment, write it back.

It enforced nothing. I fired 27 sequential requests at it during verification and every one returned 200.

KV is eventually consistent — reads can be served from a stale edge cache for up to 60 seconds. A burst of requests all read the same stale "0", increment to "1", and last-write-wins. Your counter crawls while traffic flies.

The fix: Workers has a purpose-built Rate Limiting binding that does accurate per-colo counting:

[[unsafe.bindings]]
name = "ANON_LIMITER"
type = "ratelimit"
namespace_id = "1001"
simple = { limit = 10, period = 60 }

const { success } = await env.ANON_LIMITER.limit({ key: clientIP });
if (!success) return json({ error: "Rate limit exceeded…" }, 429);

After the fix, a parallel burst of 16 requests: 5×200, 11×429. I kept the KV daily counter as a slow backstop — it does converge, just not fast enough to stop bursts on its own.

Lesson: use KV for caching, use the rate-limit binding (or Durable Objects) for counting.

Other things that mattered

SSRF guard: reject localhost, RFC-1918 ranges, .local/.internal hosts before fetching. An URL-fetching API is an SSRF machine if you skip this.
Honest status reporting: sites behind aggressive bot protection (e.g. Stack Overflow) return their challenge page. LinkPeek reports the target's real status instead of pretending.
Non-HTML targets: a HEAD-ish fallback returns type: "file" with content type for images/PDFs instead of erroring.

Try it

Live demo + docs: https://linkpeek.dpears.workers.dev (25 req/day anonymous)
Marketplace (500 req/mo free plan): https://rapidapi.com/davispearson93/api/linkpeek-link-preview-and-opengraph-metadata
npm client: https://www.npmjs.com/package/linkpeek-client
Source: https://github.com/daviscodesbugs/linkpeek

Happy to answer questions about HTMLRewriter, the rate-limit binding, or Workers KV quirks in the comments.