DEV Community: eatyou eatyou

How to Add Link Previews to Your React App (With Code Examples)

eatyou eatyou — Fri, 20 Mar 2026 05:40:34 +0000

When users share links in your React app, showing a rich preview — title, description, image — makes the experience feel polished and professional. Think Slack, Notion, or Twitter.

In this guide, I'll show you two approaches: building it from scratch, and using an API to skip the hard parts.

Why Link Previews Are Tricky

To generate a preview, you need to fetch the target URL and parse its <meta> tags (Open Graph, Twitter Cards, etc.). Simple in theory, but:

CORS blocks you — browsers won't let you fetch arbitrary URLs from the frontend
JavaScript-rendered sites — many pages need a headless browser to get the right tags
Performance — fetching external URLs on every render tanks UX
Rate limiting — sites may block your scraper

The only real solution is a backend proxy.

Approach 1: Build Your Own Backend Proxy

Create a small Node.js endpoint that fetches the URL server-side and parses the meta tags:

// server.js (Express)
const express = require('express');
const axios = require('axios');
const cheerio = require('cheerio');

const app = express();

app.get('/api/preview', async (req, res) => {
  const { url } = req.query;
  if (!url) return res.status(400).json({ error: 'url required' });

  try {
    const { data } = await axios.get(url, {
      headers: { 'User-Agent': 'Mozilla/5.0' },
      timeout: 8000,
    });
    const $ = cheerio.load(data);
    const get = (selector) => $(selector).attr('content') || '';

    res.json({
      title:
        get('meta[property="og:title"]') ||
        get('meta[name="twitter:title"]') ||
        $('title').text(),
      description:
        get('meta[property="og:description"]') ||
        get('meta[name="description"]'),
      image:
        get('meta[property="og:image"]') ||
        get('meta[name="twitter:image"]'),
      favicon: `${new URL(url).origin}/favicon.ico`,
    });
  } catch (err) {
    res.status(500).json({ error: 'Failed to fetch URL' });
  }
});

app.listen(3001);

Now your React component calls your own backend:

// LinkPreview.jsx
import { useState, useEffect } from 'react';

export function LinkPreview({ url }) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(`/api/preview?url=${encodeURIComponent(url)}`)
      .then((r) => r.json())
      .then((d) => { setData(d); setLoading(false); });
  }, [url]);

  if (loading) return <div className="preview-skeleton" />;
  if (!data?.title) return null;

  return (
    <a href={url} target="_blank" rel="noopener noreferrer" className="link-preview">
      {data.image && (
        <img src={data.image} alt={data.title} className="preview-image" />
      )}
      <div className="preview-body">
        <div className="preview-title">{data.title}</div>
        {data.description && (
          <div className="preview-desc">{data.description}</div>
        )}
        <div className="preview-domain">
          {data.favicon && <img src={data.favicon} width={14} height={14} alt="" />}
          {new URL(url).hostname}
        </div>
      </div>
    </a>
  );
}

Add some CSS:

.link-preview {
  display: flex;
  border: 1px solid #e2e8f0;
  border-radius: 8px;
  overflow: hidden;
  text-decoration: none;
  color: inherit;
  max-width: 500px;
  transition: box-shadow 0.2s;
}
.link-preview:hover { box-shadow: 0 4px 12px rgba(0,0,0,0.1); }
.preview-image { width: 120px; object-fit: cover; flex-shrink: 0; }
.preview-body { padding: 12px; }
.preview-title { font-weight: 600; font-size: 14px; margin-bottom: 4px; }
.preview-desc {
  font-size: 12px; color: #64748b; margin-bottom: 8px;
  display: -webkit-box; -webkit-line-clamp: 2;
  -webkit-box-orient: vertical; overflow: hidden;
}
.preview-domain { font-size: 11px; color: #94a3b8; display: flex; align-items: center; gap: 4px; }
.preview-skeleton { height: 80px; background: #f1f5f9; border-radius: 8px; animation: pulse 1.5s infinite; }
@keyframes pulse { 0%,100% { opacity:1 } 50% { opacity:0.5 } }

The Problems With DIY

The Cheerio approach works for static sites. But you'll quickly hit:

SPAs (React, Next.js apps) that render meta tags client-side — Cheerio sees empty tags
Paywalled sites that block scrapers
Timeouts on slow URLs that block your API response
Maintenance — you now own a scraping service

For a side project or MVP this is fine. For production with high volume, you probably want to offload this.

Approach 2: Use a Link Preview API

Instead of maintaining your own scraper, you can call a dedicated API. Here's the same component using LinkPeek:

import { useState, useEffect } from 'react';

const LINKPEEK_KEY = process.env.REACT_APP_LINKPEEK_KEY;

export function LinkPreview({ url }) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const apiUrl =
      `https://linkpeek-api.linkpeek.workers.dev/v1/preview` +
      `?url=${encodeURIComponent(url)}&key=${LINKPEEK_KEY}`;

    fetch(apiUrl)
      .then((r) => r.json())
      .then((d) => { setData(d); setLoading(false); });
  }, [url]);

  if (loading) return <div className="preview-skeleton" />;
  if (!data?.title) return null;

  return (
    <a href={url} target="_blank" rel="noopener noreferrer" className="link-preview">
      {data.image && <img src={data.image} alt={data.title} className="preview-image" />}
      <div className="preview-body">
        <div className="preview-title">{data.title}</div>
        {data.description && <div className="preview-desc">{data.description}</div>}
        <div className="preview-domain">
          {data.favicon && <img src={data.favicon} width={14} height={14} alt="" />}
          {new URL(url).hostname}
        </div>
      </div>
    </a>
  );
}

No backend needed — you call the API directly from React (CORS is handled). Free tier: 100 requests/day.

Handling Multiple URLs

If you need to preview a list of URLs (like a feed), cache results to avoid redundant requests:

import { useState, useEffect } from 'react';

// Simple in-memory cache
const cache = new Map();

export function useLinkPreview(url) {
  const [data, setData] = useState(cache.get(url) || null);
  const [loading, setLoading] = useState(!cache.has(url));

  useEffect(() => {
    if (cache.has(url)) return;

    const controller = new AbortController();
    const apiUrl =
      `https://linkpeek-api.linkpeek.workers.dev/v1/preview` +
      `?url=${encodeURIComponent(url)}&key=${process.env.REACT_APP_LINKPEEK_KEY}`;

    fetch(apiUrl, { signal: controller.signal })
      .then((r) => r.json())
      .then((d) => { cache.set(url, d); setData(d); setLoading(false); })
      .catch(() => setLoading(false));

    return () => controller.abort();
  }, [url]);

  return { data, loading };
}

Use it like:

function FeedItem({ url }) {
  const { data, loading } = useLinkPreview(url);
  // render...
}

Summary

Approach	Pros	Cons
DIY Express proxy	Full control, no cost	Maintenance, misses SPAs, CORS setup
Link Preview API	Zero backend, handles edge cases	External dependency

For most React apps, starting with a dedicated API is the pragmatic choice. If you outgrow it or need custom behavior, you can always build your own backend later.

Free API key at linkpeek-api.linkpeek.workers.dev — register with your email and get 100 requests/day instantly.

Questions about the implementation? Drop them in the comments.

How I Built a Website Health Scanner Inside Cloudflare Workers (And the Constraints I Hit)

eatyou eatyou — Fri, 20 Mar 2026 03:03:40 +0000

I wanted one tool instead of opening four browser tabs every time I launched a website.

PageSpeed Insights for performance. SecurityHeaders.com for security headers. Manual checks for meta tags and Open Graph. A separate accessibility checker. It was tedious, and I kept forgetting steps.

So I built WebPulse — a scanner that runs performance, SEO, security, and accessibility checks in a single request. Here's what I learned building it on Cloudflare Workers.

The Stack

Cloudflare Workers — edge runtime, 330+ locations worldwide
Hono — lightweight router that runs perfectly on Workers
D1 — Cloudflare's SQLite-at-the-edge database
TypeScript — because I like catching bugs before runtime

Constraint #1: No DOM API

The biggest surprise: Cloudflare Workers don't have a DOM. No document.querySelector, no DOMParser, nothing.

Most website scanners run in Node.js or a headless browser where you can do:

const dom = new DOMParser().parseFromString(html, 'text/html');
const title = dom.querySelector('title').textContent;

Inside Workers, that throws immediately.

My solution: a regex-based HTML parser from scratch. It sounds scary, but for the structured data I needed (title tags, meta descriptions, heading hierarchy, alt attributes), regex works surprisingly well:

function extractTitle(html: string): string | null {
  const match = html.match(/<title[^>]*>([^<]+)<\/title>/i);
  return match ? match[1].trim() : null;
}

function extractMetaContent(html: string, name: string): string | null {
  const pattern = new RegExp(
    `<meta[^>]+name=["']${name}["'][^>]+content=["']([^"']+)["']`,
    'i'
  );
  const match = html.match(pattern);
  return match ? match[1] : null;
}

The tricky part was handling attribute order variations — <meta content="..." name="description"> vs <meta name="description" content="...">. I ended up writing a generic attribute extractor that handles both orderings.

Constraint #2: CPU Time Limits

Workers on the free plan have a 10ms CPU time budget per request (not wall-clock time — actual CPU time). Paid plans are more generous, but I wanted to stay efficient.

A full scan involves:

Fetching the target URL
Parsing response headers
Parsing HTML (regex is CPU-intensive on large pages)
Running 20+ individual checks
Computing weighted scores
Writing results to D1

The fetch is I/O-bound and doesn't count against CPU time. The parsing does.

I profiled my checks and found a few culprits — mostly checks that were scanning the entire HTML multiple times. The fix was a single-pass extraction that pulls all the data I need in one scan, then runs checks against the extracted data.

Constraint #3: Scoring Across Different Severity Levels

This was the most interesting design problem. How do you combine a score for "missing meta description" with a score for "no HTTPS"?

They're not the same kind of problem. A missing meta description hurts SEO mildly. No HTTPS is a serious security issue that browsers actively warn users about.

I ended up with a weighted scoring system where security issues can cap the overall grade more aggressively:

function computeOverallScore(scores: DimensionScores): number {
  const weighted =
    scores.performance * 0.25 +
    scores.seo * 0.30 +
    scores.security * 0.25 +
    scores.accessibility * 0.20;

  // Security issues cap the overall grade
  if (scores.security < 40) return Math.min(weighted, 50);
  if (scores.security < 60) return Math.min(weighted, 65);

  return Math.round(weighted);
}

This means a site with great SEO but terrible security can't get an A. Feels right.

What the Scanner Actually Checks

Performance (25%): TTFB, HTML size, render-blocking resources, compression (gzip/brotli), image optimization signals

SEO (30%): Title tag, meta description, H1 presence, heading hierarchy, Open Graph tags, canonical URL, robots meta, lang attribute

Security (25%): HTTPS enforcement, HSTS header, Content Security Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy

Accessibility (20%): Image alt text coverage, form label associations, document language, viewport meta, semantic HTML elements, descriptive link text

Interesting Edge Cases

Redirect chains: Some sites redirect HTTP → HTTPS → www → non-www. I follow up to 3 redirects but flag the chain length in the performance score.

Servers that return 200 for everything: Some servers respond 200 OK to any URL, including /robots.txt when it doesn't exist. I check response body length and content type as secondary signals.

CSP complexity: Content-Security-Policy headers can be extremely long. I check for presence and whether unsafe-inline or unsafe-eval are used, rather than trying to fully validate the policy.

The Result

Scans complete in 2–4 seconds. The edge deployment means the Worker runs close to the target server geographically, which keeps fetch latency low.

Try it at webpulse-api.linkpeek.workers.dev — no signup required.

If you've built scraping or analysis tools on Workers, I'd be curious how you handled the CPU time constraint — there's probably a smarter approach than what I did.

"Debugging Open Graph Tags: Why Your Link Previews Look Wrong"

eatyou eatyou — Fri, 20 Mar 2026 02:15:24 +0000

You added all the Open Graph tags. You deployed. You paste the URL into Slack or Twitter — and the preview is wrong, blank, or showing an old image from three months ago.

Here is a systematic guide to diagnosing and fixing broken link previews.

Step 1: Check if Your Tags Are Actually in the HTML

First, confirm the tags exist and are correct in the raw HTML. Do not trust your browser's "view source" — that shows the initial HTML, not what JavaScript may inject later.

Use curl to see exactly what a crawler receives:

curl -A "facebookexternalhit/1.1" -L "https://yoursite.com/page" | grep -i "og:"

The -A flag sets the User-Agent to Facebook's crawler. Some sites serve different HTML to bots, so this matters.

You should see output like:

<meta property="og:title" content="Your Title" />
<meta property="og:image" content="https://yoursite.com/image.png" />

If you see nothing, the tags are either missing or rendered by JavaScript (see below).

Step 2: The JavaScript Rendering Problem

Open Graph tags must be in the initial server-rendered HTML. Most social crawlers do not execute JavaScript.

If your site is a React SPA that injects meta tags via document.title or a library like react-helmet without server-side rendering, crawlers will never see your OG tags.

Symptoms:

Tags look correct in browser DevTools
curl returns no OG tags
Link previews are blank

Solutions:

Enable SSR or static generation (Next.js, Nuxt, Astro, etc.)
Use a prerendering service (Prerender.io, Rendertron)
Set tags server-side before sending the HTML response

Quick test: compare curl output vs browser source:

# What crawlers see
curl -s "https://yoursite.com" | grep "og:image"

# If different from browser source, JS rendering is your problem

Step 3: Platform Cache Is Showing Old Data

This is the most common source of confusion. You fixed your tags but the preview still shows old content. That is because every platform caches OG data independently, often for days.

Force a cache refresh:

Platform	How to Refresh
Facebook	Sharing Debugger → Scrape Again
LinkedIn	Post Inspector → Inspect
Twitter/X	Card Validator
Slack	Re-paste the URL; or use `/` command to unfurl
Discord	Append `?v=2` to the URL temporarily
Telegram	Bot Father has no manual refresh; usually updates within hours

Key insight: even after you refresh Facebook's cache, users who already saw the old preview in a post will still see the old version. The cache refresh only affects new shares.

Step 4: Check Your Image URL

The og:image URL is the most common source of broken previews. Run through this checklist:

Is it absolute?

<!-- Wrong -->
<meta property="og:image" content="/images/og.png" />

<!-- Right -->
<meta property="og:image" content="https://yoursite.com/images/og.png" />

Is it HTTPS?

HTTP images often fail silently on HTTPS pages. Check:

curl -I "https://yoursite.com/images/og.png"
# Should return 200, not 301/403/404

Is it accessible without authentication?

Crawlers cannot log in. Images behind auth walls, VPN, or IP allowlists will fail.

Does it meet size requirements?

Platform	Minimum	Recommended
Facebook	200×200px	1200×630px
Twitter	144×144px	1200×675px
LinkedIn	200×200px	1200×627px

Images below the minimum are silently ignored.

Is the Content-Type correct?

curl -sI "https://yoursite.com/og.png" | grep content-type
# Should be: content-type: image/png or image/jpeg

Some servers return application/octet-stream for images, which crawlers reject.

Step 5: Encoding and Special Characters

If your title or description contains special HTML characters, they must be properly escaped:

<!-- Wrong — will break the tag -->
<meta property="og:title" content="5 Tips & Tricks for <Developers>" />

<!-- Right -->
<meta property="og:title" content="5 Tips &amp; Tricks for &lt;Developers&gt;" />

Also watch out for:

Smart quotes (" ") — fine in content, but not as attribute delimiters
Newlines inside attribute values — break the tag
Missing closing /> — can invalidate subsequent tags

Step 6: Duplicate Tags

If you have a CMS, template engine, or third-party plugin, you may end up with duplicate OG tags. Most platforms use the first match, but some use the last, and behavior varies.

curl -s "https://yoursite.com" | grep -c "og:title"
# Should be 1, not 2 or 3

Common causes: WordPress Yoast + theme hardcoded tags, or a header partial included twice.

Step 7: The `og:url` Mismatch

If your og:url does not match the actual URL being shared, Facebook in particular will associate the metadata with the canonical URL, not the shared URL. This causes weird de-duplication where multiple different URLs show the same preview.

<!-- Make sure this exactly matches the canonical URL -->
<meta property="og:url" content="https://yoursite.com/exact-page-url" />

A Debugging Script

Here is a Node.js script that checks OG tags for any URL and reports common issues:

async function debugOG(url) {
  const res = await fetch(url, {
    headers: { 'User-Agent': 'facebookexternalhit/1.1' }
  });
  const html = await res.text();

  const get = (prop) => {
    const m = html.match(
      new RegExp(`<meta[^>]+property=["']${prop}["'][^>]+content=["']([^"']+)["']`, 'i')
    ) || html.match(
      new RegExp(`<meta[^>]+content=["']([^"']+)["'][^>]+property=["']${prop}["']`, 'i')
    );
    return m ? m[1] : null;
  };

  const title = get('og:title');
  const description = get('og:description');
  const image = get('og:image');
  const ogUrl = get('og:url');

  console.log('og:title:', title || '❌ MISSING');
  console.log('og:description:', description || '⚠️  MISSING');
  console.log('og:image:', image || '❌ MISSING');
  console.log('og:url:', ogUrl || '⚠️  MISSING');

  if (image) {
    if (!image.startsWith('https://')) {
      console.warn('⚠️  og:image is not HTTPS:', image);
    }
    if (image.startsWith('/')) {
      console.error('❌ og:image is a relative URL:', image);
    }
  }

  if (ogUrl && ogUrl !== url) {
    console.warn('⚠️  og:url does not match requested URL');
  }
}

debugOG('https://yoursite.com/page');

Tools That Do This For You

If you would rather not parse HTML yourself, there are APIs that handle the full extraction pipeline — including redirect following, charset detection, and relative URL resolution.

LinkPeek is a free option:

curl "https://linkpeek-api.linkpeek.workers.dev/v1/preview?url=https://yoursite.com/page&key=YOUR_KEY"

Returns:

{
  "title": "Your Page Title",
  "description": "Your description",
  "image": "https://yoursite.com/og-image.png",
  "favicon": "https://yoursite.com/favicon.ico"
}

Useful for sanity-checking what an external crawler actually sees from your page.

Summary Checklist

When a link preview looks wrong, work through this list in order:

[ ] Tags exist in server-rendered HTML (not just JS-rendered)
[ ] og:image is an absolute HTTPS URL
[ ] Image is accessible without auth and returns the right Content-Type
[ ] Image meets minimum size requirements (1200×630px recommended)
[ ] Special characters are HTML-encoded
[ ] No duplicate og:title or og:image tags
[ ] og:url matches the canonical URL
[ ] Platform cache has been force-refreshed

Nine times out of ten, it is one of the first three items on this list.

Twitter Cards vs Open Graph: What's the Difference and Which Should You Use?

eatyou eatyou — Fri, 20 Mar 2026 02:10:02 +0000

If you have ever pasted a link into Twitter, Slack, or iMessage and seen a rich card appear, you have witnessed two competing standards doing their job: Open Graph (from Facebook) and Twitter Cards (from Twitter/X).

They often get used interchangeably, but they have real differences. Here is what you need to know.

The Short Answer

Open Graph is the universal standard — LinkedIn, Discord, Slack, iMessage, WhatsApp, and most other platforms read it.
Twitter Cards are Twitter's own extension — they add features Open Graph lacks, like player cards and app cards.
In practice: implement Open Graph first, then add Twitter-specific tags for the extras.

Open Graph Protocol

Created by Facebook in 2010, Open Graph (og:) is now the de facto standard for link metadata across the web.

<head>
  <meta property="og:title" content="Your Page Title" />
  <meta property="og:description" content="A one or two sentence description." />
  <meta property="og:image" content="https://yoursite.com/og-image.png" />
  <meta property="og:url" content="https://yoursite.com/page" />
  <meta property="og:type" content="website" />
  <meta property="og:site_name" content="Your Site" />
</head>

Image Requirements for Open Graph

Platform	Recommended Size	Min Size	Aspect Ratio
Facebook	1200×630px	600×315px	1.91:1
LinkedIn	1200×627px	200×200px	~1.91:1
Discord	Any reasonable	64×64px	Flexible
iMessage	1200×630px	—	1.91:1

The safest bet: 1200×630px, JPEG or PNG, under 8MB.

Twitter Cards

Twitter supports Open Graph tags but also has its own twitter: namespace with additional card types.

Summary Card (default)

Shows a small thumbnail on the left:

<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@yourhandle" />
<meta name="twitter:title" content="Your Title" />
<meta name="twitter:description" content="Your description." />
<meta name="twitter:image" content="https://yoursite.com/image.png" />

Summary Card with Large Image

Full-width image above the text — the most visually impactful:

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@yourhandle" />
<meta name="twitter:creator" content="@authorhandle" />
<meta name="twitter:title" content="Your Title" />
<meta name="twitter:description" content="Your description." />
<meta name="twitter:image" content="https://yoursite.com/large-image.png" />
<meta name="twitter:image:alt" content="Description of the image" />

Twitter recommends 1200×675px for large image cards — slightly different from the OG 1200×630 standard.

App Card

For mobile app landing pages:

<meta name="twitter:card" content="app" />
<meta name="twitter:app:id:iphone" content="123456789" />
<meta name="twitter:app:id:googleplay" content="com.yourapp" />

Player Card

Embeds video or audio directly in the timeline — requires Twitter approval:

<meta name="twitter:card" content="player" />
<meta name="twitter:player" content="https://yoursite.com/embed/video123" />
<meta name="twitter:player:width" content="1280" />
<meta name="twitter:player:height" content="720" />

How Twitter Falls Back to Open Graph

Here is the important part: Twitter reads Open Graph tags if Twitter Cards are missing.

The fallback order:

twitter:title → fallback to og:title
twitter:description → fallback to og:description
twitter:image → fallback to og:image

So if your Open Graph tags are already set up correctly and you just want a summary_large_image card on Twitter, you only need to add two tags:

<!-- Your existing OG tags cover the rest -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@yourhandle" />

The Complete Template

Here is a full, production-ready head section combining both:

<head>
  <!-- Primary meta -->
  <title>Your Page Title</title>
  <meta name="description" content="Your page description." />

  <!-- Open Graph (used by Facebook, LinkedIn, Discord, Slack, iMessage, WhatsApp, etc.) -->
  <meta property="og:title" content="Your Page Title" />
  <meta property="og:description" content="Your page description." />
  <meta property="og:image" content="https://yoursite.com/og-image.png" />
  <meta property="og:image:width" content="1200" />
  <meta property="og:image:height" content="630" />
  <meta property="og:image:alt" content="Description of the image" />
  <meta property="og:url" content="https://yoursite.com/this-page" />
  <meta property="og:type" content="website" />
  <meta property="og:site_name" content="Your Site Name" />
  <meta property="og:locale" content="en_US" />

  <!-- Twitter Cards (only need these extras beyond OG) -->
  <meta name="twitter:card" content="summary_large_image" />
  <meta name="twitter:site" content="@yourhandle" />
  <meta name="twitter:creator" content="@authorhandle" />

  <!-- Canonical URL -->
  <link rel="canonical" href="https://yoursite.com/this-page" />
</head>

Common Mistakes

1. Using a relative URL for og:image.

Wrong:

<meta property="og:image" content="/images/og.png" />

Right:

<meta property="og:image" content="https://yoursite.com/images/og.png" />

Most crawlers do not follow relative URLs. Always use absolute URLs.

2. Image too small. Facebook ignores images smaller than 200×200px. Always use at least 600×315px.

3. Different titles in OG and Twitter. If you set both, make sure they match. Inconsistency looks like a bug.

4. Missing og:url. Without it, Facebook uses the current page URL, which can cause issues with shared URLs that have tracking parameters.

5. HTTP image on an HTTPS page. Mixed content will cause the image not to load on many platforms. All your OG images should be served over HTTPS.

Platform Debugging Tools

Platform	Tool
Facebook	Sharing Debugger
Twitter/X	Card Validator
LinkedIn	Post Inspector
Generic	OpenGraph.xyz

One important note: all these platforms cache previews. After you update your tags, you need to use the debugger tool to force a re-scrape, or the old version will still appear for hours or days.

Dynamic OG Images

Static OG images are easy but miss an opportunity. For blogs, documentation sites, and SaaS apps, dynamically generated OG images that include the page title convert much better.

Popular approaches:

Vercel OG (@vercel/og) — React components rendered to image at the edge
Puppeteer/Playwright — screenshot a styled HTML template
Canvas API on a server — programmatic image generation
A metadata API — let someone else handle the fetching; focus on your own image assets

Tools like LinkPeek extract the existing metadata and image from any URL, so you can render your own preview card without writing a scraper.

Summary

Feature	Open Graph	Twitter Cards
Universal support	✅	❌ (Twitter only)
Large image card	Via `og:image`	`summary_large_image`
Video/audio embed	❌	✅ `player` card
App store links	❌	✅ `app` card
Fallback chain	Base standard	Falls back to OG

The rule of thumb: implement Open Graph completely, add twitter:card and twitter:site, and you cover 95% of platforms with minimal effort.

The Developer's Pre-Launch Checklist: 40 Things to Check Before Shipping

eatyou eatyou — Wed, 18 Mar 2026 05:42:59 +0000

You built the feature. Tests pass. Staging looks good. Time to ship, right?

Not so fast. I've shipped enough broken things to know that there's a gap between "it works" and "it's ready." This is my checklist — the things I verify before every launch.

Not everything applies to every project. Skip what's irrelevant. But scan the whole list at least once.

Performance

[ ] Page loads in under 3 seconds on a throttled connection (Chrome DevTools → Network → Slow 3G)
[ ] Images are optimized — use WebP/AVIF, lazy-load below-the-fold images, serve responsive sizes
[ ] No render-blocking resources — CSS and JS that block first paint are deferred or inlined
[ ] Bundle size is reasonable — run npx bundlephobia or check your framework's build output
[ ] API responses are fast — P95 latency under 500ms for critical endpoints
[ ] Caching headers are set — static assets have Cache-Control: public, max-age=31536000, immutable with hashed filenames

SEO & Social Sharing

[ ] Every page has a unique <title> — under 60 characters, descriptive
[ ] Every page has a <meta description> — 120-160 characters
[ ] Open Graph tags are set — og:title, og:description, og:image (1200x630px, absolute URL)
[ ] Twitter Card tag is set — twitter:card = summary_large_image
[ ] og:image works — test with Facebook Sharing Debugger
[ ] Canonical URLs are set — <link rel="canonical"> on every page
[ ] robots.txt exists — allows indexing of public pages, blocks admin/API routes
[ ] sitemap.xml exists — lists all public URLs
[ ] Structured data is valid — test with Google's Rich Results Test

Security

[ ] HTTPS everywhere — no mixed content, HSTS header set
[ ] No secrets in client code — API keys, tokens, and passwords are server-side only
[ ] Input validation — all user input is validated server-side (don't trust client validation)
[ ] SQL injection protected — use parameterized queries, never string concatenation
[ ] XSS protected — user content is escaped before rendering in HTML
[ ] CSRF protection — state-changing requests require a CSRF token
[ ] Rate limiting — login, registration, and API endpoints have rate limits
[ ] CORS configured — only your domains are allowed, not * in production
[ ] Dependencies audited — run npm audit or pip audit, fix critical vulnerabilities
[ ] No .env or credentials in the repository — check with git log --all -p | grep -i 'password\|secret\|api_key'

Accessibility

[ ] All images have alt text — descriptive for content images, empty for decorative ones
[ ] Keyboard navigation works — tab through the entire page, ensure all interactive elements are reachable
[ ] Color contrast passes — use Chrome DevTools accessibility audit or axe-core
[ ] Form labels exist — every <input> has an associated <label>
[ ] Focus indicators are visible — don't remove :focus outlines without replacing them

Error Handling

[ ] 404 page exists — custom, helpful, includes navigation back to the main site
[ ] 500 errors don't leak stack traces — production error pages are generic
[ ] API errors return consistent format — { error: "message" } with appropriate HTTP status codes
[ ] Error monitoring is set up — Sentry, LogRocket, or similar

Mobile

[ ] Viewport meta tag is set — <meta name="viewport" content="width=device-width, initial-scale=1.0">
[ ] Tested on real devices — or at minimum, Chrome DevTools device emulation
[ ] Touch targets are large enough — minimum 44x44px for buttons and links
[ ] No horizontal scroll — nothing overflows the viewport

Monitoring & Analytics

[ ] Uptime monitoring — UptimeRobot (free), Pingdom, or similar
[ ] Analytics installed — you know how many people visit and where they come from
[ ] Error tracking — you get notified when things break
[ ] Performance monitoring — track Core Web Vitals over time

Launch Day

[ ] DNS is configured — if using a custom domain, records are set and propagated
[ ] SSL certificate is valid — not expired, covers all subdomains you use
[ ] Redirects work — old URLs redirect to new ones (301, not 302)
[ ] Backup exists — database backup taken before any migration
[ ] Rollback plan — you know how to revert if things go wrong
[ ] Team is online — someone is available to respond to issues

The Meta-Checklist

Before using this checklist:

Don't let it block you from shipping. A shipped product with imperfect SEO tags beats a perfect product that never launches.
Prioritize by impact. Security issues > broken functionality > performance > SEO > nice-to-haves.
Automate what you can. Lighthouse CI, ESLint, npm audit, and pre-commit hooks catch many of these automatically.
Revisit after launch. Some things (analytics data, real-world performance) can only be evaluated after real users interact with your product.

Tools I Use for Each Category

Category	Tool	Free?
Performance	Lighthouse, WebPageTest	Yes
SEO	Google Search Console, Ahrefs Webmaster	Yes
OG Tags	Facebook Sharing Debugger, metadata extraction APIs	Yes
Security	npm audit, Snyk, OWASP ZAP	Yes
Accessibility	axe DevTools, Lighthouse	Yes
Monitoring	UptimeRobot, Sentry (free tier)	Yes
Analytics	Plausible, Umami, Cloudflare Analytics	Varies

Print It, Pin It

I keep a printed copy of this next to my monitor. Every time I'm about to click "Deploy," I scan through it. It takes 5 minutes and has saved me from embarrassing launches more times than I can count.

What's on your pre-launch checklist that I missed? I'm always looking to improve mine.

Building a Favicon Finder: Why It's Harder Than You Think

eatyou eatyou — Wed, 18 Mar 2026 04:35:15 +0000

How hard can it be to get a website's favicon? Just fetch /favicon.ico, right?

Wrong. I tried building a reliable favicon finder and fell down a rabbit hole of legacy standards, broken markup, and bizarre edge cases.

Here's everything I learned.

The Naive Approach

const faviconUrl = new URL('/favicon.ico', siteUrl).href;

This works for maybe 70% of sites. For the rest, you'll get a 404, a redirect to the homepage, or a 1x1 transparent pixel.

The Problem: There's No Single Standard

Over the years, multiple ways to specify favicons have emerged:

1. The Original: /favicon.ico

From the late 1990s. Browsers would automatically look for /favicon.ico at the root of every domain. No HTML tag needed.

https://example.com/favicon.ico

Problem: Many modern sites don't have a file at this path anymore.

2. HTML Link Tags (Many Variants)

<!-- Standard -->
<link rel="icon" href="/favicon.png">

<!-- With type -->
<link rel="icon" type="image/png" href="/favicon-32x32.png">

<!-- Legacy IE -->
<link rel="shortcut icon" href="/favicon.ico">

<!-- Apple Touch Icon -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="apple-touch-icon-precomposed" href="/apple-touch-icon-precomposed.png">

<!-- Sized variants -->
<link rel="icon" sizes="16x16" href="/favicon-16x16.png">
<link rel="icon" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" sizes="192x192" href="/android-chrome-192x192.png">

<!-- SVG favicon (modern) -->
<link rel="icon" type="image/svg+xml" href="/favicon.svg">

<!-- Mask icon (Safari pinned tabs) -->
<link rel="mask-icon" href="/safari-pinned-tab.svg" color="#5bbad5">

That's at least 10 different ways to specify a favicon in HTML.

3. Web App Manifest

<link rel="manifest" href="/site.webmanifest">

The manifest file contains icons:

{
  "icons": [
    { "src": "/android-chrome-192x192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/android-chrome-512x512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

4. Microsoft browserconfig.xml

<browserconfig>
  <msapplication>
    <tile>
      <square150x150logo src="/mstile-150x150.png"/>
    </tile>
  </msapplication>
</browserconfig>

Yes, really.

The Algorithm That Works

After testing against hundreds of sites, here's the priority order that produces the best results:

async function findFavicon(url) {
  const html = await fetchHTML(url);
  const baseUrl = new URL(url).origin;
  const doc = parseHTML(html);

  // Priority 1: SVG favicon (best quality, scales perfectly)
  const svg = doc.querySelector('link[rel="icon"][type="image/svg+xml"]');
  if (svg?.getAttribute('href')) {
    return resolveUrl(svg.getAttribute('href'), baseUrl);
  }

  // Priority 2: apple-touch-icon (usually high-res, 180x180)
  const apple = doc.querySelector(
    'link[rel="apple-touch-icon"], link[rel="apple-touch-icon-precomposed"]'
  );
  if (apple?.getAttribute('href')) {
    return resolveUrl(apple.getAttribute('href'), baseUrl);
  }

  // Priority 3: Largest explicit icon
  const icons = doc.querySelectorAll('link[rel="icon"], link[rel="shortcut icon"]');
  if (icons.length > 0) {
    // Sort by size (largest first)
    const sorted = [...icons].sort((a, b) => {
      const sizeA = parseInt(a.getAttribute('sizes')?.split('x')[0] || '0');
      const sizeB = parseInt(b.getAttribute('sizes')?.split('x')[0] || '0');
      return sizeB - sizeA;
    });
    const href = sorted[0].getAttribute('href');
    if (href) return resolveUrl(href, baseUrl);
  }

  // Priority 4: Web app manifest
  const manifest = doc.querySelector('link[rel="manifest"]');
  if (manifest?.getAttribute('href')) {
    try {
      const manifestUrl = resolveUrl(manifest.getAttribute('href'), baseUrl);
      const manifestData = await fetch(manifestUrl).then(r => r.json());
      if (manifestData.icons?.length) {
        const largest = manifestData.icons.sort(
          (a, b) => parseInt(b.sizes?.split('x')[0] || '0') - parseInt(a.sizes?.split('x')[0] || '0')
        )[0];
        return resolveUrl(largest.src, baseUrl);
      }
    } catch {}
  }

  // Priority 5: Default /favicon.ico
  const defaultFavicon = `${baseUrl}/favicon.ico`;
  try {
    const res = await fetch(defaultFavicon, { method: 'HEAD' });
    if (res.ok && res.headers.get('content-type')?.includes('image')) {
      return defaultFavicon;
    }
  } catch {}

  // Priority 6: Google's favicon service (public fallback)
  return `https://www.google.com/s2/favicons?domain=${new URL(url).hostname}&sz=64`;
}

function resolveUrl(href, baseUrl) {
  if (href.startsWith('//')) return 'https:' + href;
  if (href.startsWith('http')) return href;
  return new URL(href, baseUrl).href;
}

Edge Cases That Will Ruin Your Day

1. Data URIs as Favicons

Some sites inline their favicon as a data URI:

<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>🔥</text></svg>">

This is valid! GitHub uses an emoji favicon via data URI. Your parser needs to handle this — it's not a URL you can fetch, but you can use it directly.

2. Relative Paths with Subdirectories

<!-- On https://example.com/blog/post -->
<link rel="icon" href="../images/favicon.png">
<!-- Resolves to: https://example.com/images/favicon.png -->

Always resolve against the page URL, not just the origin.

3. Protocol-Relative URLs

<link rel="icon" href="//cdn.example.com/favicon.png">

Still used in the wild. Prepend https: and move on.

4. Multiple Favicons for Different Purposes

A well-configured site might have ALL of these:

<link rel="icon" type="image/svg+xml" href="/favicon.svg">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
<link rel="mask-icon" href="/safari-pinned-tab.svg" color="#5bbad5">

Which one do you pick? It depends on your use case:

Displaying in a list/feed: 32x32 PNG or SVG
High-res display: apple-touch-icon (180x180)
Scalable: SVG

5. favicon.ico That Returns HTML

Some servers return a 200 for ANY path — including /favicon.ico — but serve the homepage HTML instead. Always check the Content-Type header:

const res = await fetch(faviconUrl, { method: 'HEAD' });
const contentType = res.headers.get('content-type') || '';

if (!contentType.startsWith('image/')) {
  // This is not actually a favicon
  return null;
}

6. CDN-Hosted Favicons with CORS Issues

If you want to display a favicon from another origin, you might hit CORS issues in the browser. Server-side fetching avoids this entirely.

Google's Favicon API: The Lazy (Smart) Option

Google maintains a public favicon service:

https://www.google.com/s2/favicons?domain=github.com&sz=64

This returns a 64x64 PNG favicon for any domain. It's reliable, fast, and handles all the edge cases for you. Available sizes: 16, 32, 64, 128, 256.

Trade-off: You're depending on Google, and there's a slight delay for uncached domains.

DuckDuckGo's Alternative

https://icons.duckduckgo.com/ip3/github.com.ico

Similar to Google's, but from DuckDuckGo. Also free and public.

Testing Your Implementation

Test against these sites — they cover most edge cases:

Site	Challenge
github.com	SVG favicon via data URI
google.com	Multiple sizes, well-configured
wikipedia.org	/favicon.ico with apple-touch-icon
reddit.com	Multiple formats
A personal blog	Likely missing or minimal
A Japanese site	Encoding + non-standard paths
localhost/127.0.0.1	Should be blocked (SSRF)

Recap

Finding a favicon reliably requires:

Parsing HTML for 10+ different link tag variants
Checking the web app manifest
Falling back to /favicon.ico
Handling relative URLs, data URIs, and protocol-relative URLs
Validating that the response is actually an image
Having a fallback (Google's API)

It's a lot more than just fetching /favicon.ico.

What's the most creative favicon you've seen in the wild? Drop it in the comments.

Web Scraping Meta Tags Without Getting Blocked — Lessons Learned

eatyou eatyou — Wed, 18 Mar 2026 04:33:18 +0000

I've spent the last few months building a system that extracts meta tags from URLs at scale. Along the way I hit every wall you can imagine — rate limits, CAPTCHAs, bot detection, encoding nightmares, and HTML so malformed it would make a parser cry.

Here's everything I learned, so you don't have to learn it the hard way.

The Simple Version (That Breaks Immediately)

Extracting meta tags seems trivial:

const res = await fetch(url);
const html = await res.text();
const title = html.match(/<title>(.*?)<\/title>/)?.[1];

This works for about 60% of websites. The other 40% will teach you humility.

Problem 1: Bot Detection

Many sites block requests that don't look like a real browser.

What Gets You Blocked

Missing or generic User-Agent header
No Accept, Accept-Language, or Accept-Encoding headers
Requesting from cloud provider IP ranges (AWS, GCP, Azure)
Making too many requests too fast
Missing TLS fingerprint characteristics

What Works

Set headers that look like a real browser:

const response = await fetch(url, {
  headers: {
    'User-Agent': 'Mozilla/5.0 (compatible; MyBot/1.0; +https://mysite.com/bot)',
    'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
    'Accept-Language': 'en-US,en;q=0.5',
    'Accept-Encoding': 'gzip, deflate',
  },
  redirect: 'follow',
});

Notice I'm identifying as a bot with a contact URL in the User-Agent. This is ethical best practice — you're being transparent about what you are. Many sites have specific bot policies and will treat identified bots better than anonymous scrapers.

Rate Limiting Yourself

Even if a site doesn't block you, be respectful:

const delay = (ms) => new Promise(resolve => setTimeout(resolve, ms));

async function fetchWithRateLimit(urls, delayMs = 1000) {
  const results = [];
  for (const url of urls) {
    results.push(await fetchMetaTags(url));
    await delay(delayMs);
  }
  return results;
}

Problem 2: Redirect Chains

A simple URL can lead you on a wild chase:

https://t.co/abc123
  → https://bit.ly/xyz789
    → https://example.com/blog?utm_source=twitter
      → https://example.com/blog/my-post
        → https://www.example.com/blog/my-post (www redirect)
          → https://www.example.com/blog/my-post/ (trailing slash)

That's 5 redirects just to reach the actual page.

How to Handle It

async function fetchWithRedirects(url, maxRedirects = 10) {
  let currentUrl = url;
  let redirectCount = 0;

  while (redirectCount < maxRedirects) {
    const response = await fetch(currentUrl, { redirect: 'manual' });

    if (response.status >= 300 && response.status < 400) {
      const location = response.headers.get('location');
      if (!location) break;

      // Handle relative redirects
      currentUrl = new URL(location, currentUrl).href;
      redirectCount++;
      continue;
    }

    return { response, finalUrl: currentUrl, redirectCount };
  }

  throw new Error(`Too many redirects (${maxRedirects})`);
}

Why redirect: 'manual'? Because you want to track the final URL. The og:url tag often differs from the URL you started with, and you need the final URL to resolve relative image paths.

Problem 3: Character Encoding

The web is not all UTF-8. You'll encounter:

Shift-JIS (Japanese sites)
EUC-KR (Korean sites)
GB2312 / GBK (Chinese sites)
ISO-8859-1 (older European sites)
Windows-1252 (legacy sites that claim ISO-8859-1 but use Windows-1252)

Detection Strategy

function detectEncoding(html, headers) {
  // 1. Check HTTP Content-Type header
  const contentType = headers.get('content-type') || '';
  const charsetMatch = contentType.match(/charset=([\w-]+)/i);
  if (charsetMatch) return charsetMatch[1];

  // 2. Check HTML meta tag
  const metaMatch = html.match(
    /<meta[^>]+charset=["']?([\w-]+)/i
  );
  if (metaMatch) return metaMatch[1];

  // 3. Check XML declaration
  const xmlMatch = html.match(
    /<\?xml[^>]+encoding=["']([\w-]+)/i
  );
  if (xmlMatch) return xmlMatch[1];

  // 4. Default to UTF-8
  return 'utf-8';
}

Problem 4: Malformed HTML

Real-world HTML is a horror show:

<!-- Unclosed tags -->
<meta property="og:title" content="Hello World>

<!-- Wrong quotes -->
<meta property='og:image' content=https://example.com/img.png>

<!-- Mixed case -->
<META PROPERTY="OG:TITLE" CONTENT="Hello">

<!-- Duplicate tags -->
<meta property="og:title" content="Title 1">
<meta property="og:title" content="Title 2">

How to Handle It

Don't use regex for the final parse. Use a proper HTML parser that handles malformed markup:

Node.js:

import { parse } from 'node-html-parser';

const root = parse(html);
const ogTitle = root.querySelector('meta[property="og:title"]')?.getAttribute('content');

Python:

from bs4 import BeautifulSoup

soup = BeautifulSoup(html, 'html.parser')
og_title = soup.find('meta', property='og:title')
title = og_title['content'] if og_title else None

For duplicates, always take the first occurrence — that's what most platforms do.

Problem 5: JavaScript-Rendered Content

Some sites render their OG tags with JavaScript. When you fetch the HTML, the <head> is empty or contains placeholder values.

This is increasingly common with SPAs (React, Vue, Angular).

Detection

If the HTML contains very little content but has large JS bundles, the site is likely JS-rendered:

function isLikelyJSRendered(html) {
  const hasMinimalBody = html.match(/<body[^>]*>[\s\S]{0,500}<\/body>/i);
  const hasReactRoot = html.includes('id="root"') || html.includes('id="app"') || html.includes('id="__next"');
  const hasNoOGTags = !html.includes('og:title');
  return (hasMinimalBody || hasReactRoot) && hasNoOGTags;
}

Solutions

Check for server-side rendered alternatives — many SPAs serve different HTML to bots based on User-Agent
Use a headless browser — Puppeteer or Playwright can execute JS, but it's 10-100x slower
Accept the limitation — if the site doesn't serve OG tags to bots, there's no metadata to extract

Problem 6: Security (SSRF)

If your scraper accepts user-provided URLs, you MUST prevent Server-Side Request Forgery:

function validateUrl(url) {
  const parsed = new URL(url);

  // Only allow HTTP(S)
  if (!['http:', 'https:'].includes(parsed.protocol)) {
    throw new Error('Only HTTP(S) URLs allowed');
  }

  // Block private/internal IPs
  const hostname = parsed.hostname;
  if (
    hostname === 'localhost' ||
    hostname === '127.0.0.1' ||
    hostname.startsWith('10.') ||
    hostname.startsWith('192.168.') ||
    hostname.startsWith('172.') ||
    hostname.endsWith('.local') ||
    hostname.endsWith('.internal')
  ) {
    throw new Error('Private URLs not allowed');
  }

  return parsed;
}

Also set a reasonable timeout (5-15 seconds) and response size limit (1-5MB) to prevent resource exhaustion.

Problem 7: Favicon Discovery

Finding a site's favicon is surprisingly hard. There's no single standard location. You need to check, in order:

function findFavicon(html, baseUrl) {
  const doc = parseHTML(html);

  // 1. Explicit link tags (various rel values)
  const selectors = [
    'link[rel="icon"]',
    'link[rel="shortcut icon"]',
    'link[rel="apple-touch-icon"]',
    'link[rel="apple-touch-icon-precomposed"]',
  ];

  for (const selector of selectors) {
    const el = doc.querySelector(selector);
    if (el?.getAttribute('href')) {
      return new URL(el.getAttribute('href'), baseUrl).href;
    }
  }

  // 2. Default /favicon.ico
  return new URL('/favicon.ico', baseUrl).href;
}

But even this isn't enough — some sites serve different favicons for different sizes, use SVG favicons, or have the favicon at a completely non-standard path.

The Architecture That Works

After all these lessons, here's the architecture I settled on:

1. Validate URL (SSRF protection)
2. Check cache (skip fetch if fresh)
3. Fetch with timeout (5s) and redirect following (max 10)
4. Detect encoding, decode to UTF-8
5. Parse HTML with a tolerant parser
6. Extract: OG tags → Twitter tags → HTML tags → fallbacks
7. Resolve relative URLs against final URL
8. Validate image URL (HEAD request, check content-type)
9. Find favicon
10. Cache result (1 hour TTL)

Each step has its own error handling. If any step fails, you still return whatever you managed to extract.

Performance Tips

Set Accept-Encoding: gzip — most sites support it, reduces transfer size by 60-80%
Only read the <head> — you don't need the full page. Stop reading after </head> or after the first 50KB
DNS caching — if you're fetching many URLs from the same domain, cache DNS lookups
Connection pooling — reuse TCP connections for same-origin requests
Parallel fetching with concurrency limits — fetch 10 URLs at once, not 1 or 1000

Wrap Up

Meta tag extraction sounds simple. It's not. The real world has encoding issues, malformed HTML, bot detection, redirect chains, JS-rendered content, and security concerns.

But once you've handled these edge cases, you have a robust system that works on 95%+ of the web. The remaining 5% are sites that actively prevent any form of scraping — and that's their right.

What's the weirdest edge case you've hit when scraping websites? I'd love to hear your war stories in the comments.

URL Unfurling: How Slack, Discord and Twitter Generate Link Previews

eatyou eatyou — Wed, 18 Mar 2026 04:20:44 +0000

You paste a URL in Slack. A second later, a rich card appears — title, description, image, favicon. Magic.

But it's not magic. It's a well-defined process called URL unfurling. Every chat app, social platform, and messaging service does it. Understanding how it works makes you a better web developer — and helps you debug why your links sometimes look broken.

Let's break it down.

What Happens When You Paste a URL

Here's the sequence, step by step:

Step 1: Detection

The app detects a URL pattern in your message. Most apps use a regex like:

https?://[^\s]+

Some apps unfurl all URLs. Others only unfurl the first one. Slack unfurls up to 5 per message.

Step 2: Server-Side Fetch

The app's server (not your browser) makes an HTTP GET request to the URL. This is important — it means:

The request comes from the app's IP, not yours
JavaScript doesn't execute (no browser engine)
The server follows redirects (usually up to 5-10 hops)
There's a timeout (typically 3-10 seconds)

GET https://example.com/blog/my-post HTTP/1.1
User-Agent: Slackbot 1.0 (+https://api.slack.com/robots)
Accept: text/html

Notice the User-Agent. You can detect unfurling bots by checking for strings like Slackbot, Twitterbot, Discordbot, LinkedInBot, WhatsApp, facebookexternalhit.

Step 3: HTML Parsing

The server parses the HTML response and extracts metadata. The priority order is usually:

Open Graph tags (og:title, og:description, og:image)
Twitter Card tags (twitter:title, twitter:description, twitter:image)
Standard HTML (<title>, <meta name="description">, <link rel="icon">)
Fallbacks (first <h1>, first paragraph, first image)

Here's simplified pseudocode of what the parser does:

function extractMetadata(html) {
  const doc = parseHTML(html);

  return {
    title: 
      doc.querySelector('meta[property="og:title"]')?.content ||
      doc.querySelector('meta[name="twitter:title"]')?.content ||
      doc.querySelector('title')?.textContent ||
      doc.querySelector('h1')?.textContent,

    description:
      doc.querySelector('meta[property="og:description"]')?.content ||
      doc.querySelector('meta[name="twitter:description"]')?.content ||
      doc.querySelector('meta[name="description"]')?.content,

    image:
      doc.querySelector('meta[property="og:image"]')?.content ||
      doc.querySelector('meta[name="twitter:image"]')?.content,

    favicon:
      doc.querySelector('link[rel="icon"]')?.href ||
      doc.querySelector('link[rel="shortcut icon"]')?.href ||
      new URL('/favicon.ico', url).href,
  };
}

Step 4: Image Validation

The app fetches the og:image URL to verify it exists, check its dimensions, and sometimes generate a thumbnail. This is why:

Broken image URLs show no preview image
Very large images take longer to unfurl
Some apps reject images under a minimum size

Step 5: Caching

The result is cached. Cache duration varies by platform:

Platform	Cache Duration	How to Clear
Slack	Per-workspace	Edit message, re-paste URL
Facebook	~24 hours	Use Sharing Debugger
Twitter	~7 days	Use Card Validator
LinkedIn	~7 days	Use Post Inspector
Discord	Minutes	Automatic

This is why fixing your OG tags doesn't immediately update old previews.

Step 6: Rendering

Finally, the app renders a preview card with the extracted metadata. The layout depends on the platform and whether an image was found.

Why Your Link Previews Break

Now that you know the process, here are the most common failure points:

1. Client-Side Rendered Content

If your page is a React/Vue/Angular SPA that renders OG tags with JavaScript, the unfurling bot won't see them. Bots don't execute JS.

Fix: Use SSR (Next.js, Nuxt, Remix) or serve OG tags from the server.

2. Redirect Chains

URL shorteners and marketing tools add redirects. Each redirect adds latency. After 5-10 hops or 3-10 seconds, the bot gives up.

Fix: Minimize redirects. Test with curl -L -v your-url to see the chain.

3. Blocking Bots

Your firewall, CDN, or rate limiter might block the unfurling bot's IP or reject its User-Agent.

Fix: Whitelist known bot User-Agents:

# Nginx example
if ($http_user_agent ~* "Slackbot|Twitterbot|Discordbot|LinkedInBot|facebookexternalhit|WhatsApp") {
  # Allow through rate limiting
}

4. Relative Image URLs

<!-- Bot can't resolve this -->
<meta property="og:image" content="/images/og.png" />

<!-- This works -->
<meta property="og:image" content="https://example.com/images/og.png" />

5. Slow Response Times

If your page takes more than 3-5 seconds to respond, the bot times out and shows no preview.

Fix: Serve a lightweight HTML response with OG tags. You don't need to server-render the full page — just the <head> section matters for unfurling.

Building Your Own Unfurler

If you're building a chat app or any app that needs link previews, here's the architecture:

[User pastes URL]
       |
       v
[URL Detection (regex)]
       |
       v
[Server-side HTTP fetch]
  - Follow redirects (max 5)
  - Timeout: 5 seconds  
  - User-Agent: "MyApp/1.0"
       |
       v
[Parse HTML for meta tags]
  - OG tags > Twitter tags > HTML tags > fallbacks
       |
       v
[Validate & fetch image]
  - Check dimensions
  - Generate thumbnail
       |
       v
[Cache result]
  - Key: URL hash
  - TTL: 1-24 hours
       |
       v
[Render preview card]

Key Design Decisions

Timeouts: Be aggressive. 5 seconds max for the HTML fetch, 5 seconds for the image. Users are waiting.

Security: Never fetch private IPs (10.x, 192.168.x, 127.x). This prevents SSRF attacks. Also block file:// and other non-HTTP schemes.

function isSafeUrl(url) {
  const parsed = new URL(url);
  if (!['http:', 'https:'].includes(parsed.protocol)) return false;
  // Block private IPs
  const ip = await resolve(parsed.hostname);
  if (isPrivateIP(ip)) return false;
  return true;
}

Caching: Cache aggressively. Most pages don't change their OG tags often. 1-hour TTL is a good default.

Concurrency: If 100 users paste the same URL at once, don't fetch it 100 times. Use request coalescing — one fetch, broadcast the result.

Build vs. Buy

Building a robust unfurler is more work than it looks:

Handling character encodings (Shift-JIS, EUC-KR, etc.)
Dealing with malformed HTML
Following redirect chains correctly
Image validation and thumbnailing
SSRF protection
Rate limiting outbound requests
Caching layer

If link previews aren't your core product, using an API is often the pragmatic choice. Options include self-hosted libraries (open-graph-scraper on npm) or hosted APIs that handle all the edge cases for you.

Testing Your Unfurling

Before sharing your URL anywhere:

Check your OG tags exist — view source, search for og:
Use platform debuggers — Facebook Sharing Debugger, Twitter Card Validator
Test from a fresh context — incognito browser, different Slack workspace
Check mobile — some platforms render previews differently on mobile
Test after deploy — cached previews from staging URLs can be misleading

Recap

URL unfurling is: detect URL → server-side fetch → parse HTML meta tags → validate image → cache → render card.

The most common problems are: missing OG tags, client-side rendering, blocking bots, and slow response times.

Now you know exactly what happens when someone pastes a link — and how to make sure yours looks good.

Building something that needs link previews? I'd be curious to hear about the edge cases you've hit.

The Complete Guide to Open Graph Tags — What Most Developers Get Wrong

eatyou eatyou — Wed, 18 Mar 2026 02:30:03 +0000

You ship a new page. Someone shares it on Slack. Instead of a rich preview card, they see... nothing. Or worse — the wrong image, a truncated title, and a description pulled from your cookie banner.

Open Graph tags control how your pages look when shared. Get them wrong and your links look broken. Get them right and every share becomes a mini billboard.

This guide covers everything: what each tag does, the mistakes I see on most sites, and how to debug them.

What is Open Graph?

Open Graph (OG) is a protocol created by Facebook in 2010. It lets you define how a URL appears when shared on social platforms, chat apps, and anywhere that generates link previews.

When someone pastes your URL in Slack, Discord, Twitter, LinkedIn, iMessage, or WhatsApp, those platforms fetch your page and look for OG tags in the <head>. If they find them, they render a rich preview card. If not, they guess — and guessing rarely goes well.

The Essential Tags

og:title

<meta property="og:title" content="How to Deploy a Node.js App to Production" />

This is the headline of your preview card. Keep it under 60 characters or it gets truncated.

Common mistake: Using the same <title> tag that includes your site name. Your HTML title might be "How to Deploy Node.js | MyBlog" but your og:title should just be "How to Deploy a Node.js App to Production" — the site name goes in og:site_name.

og:description

<meta property="og:description" content="A step-by-step guide to deploying Node.js apps with zero downtime, covering PM2, Nginx, and SSL setup." />

Aim for 120-160 characters. This is your elevator pitch.

Common mistake: Leaving this empty and letting platforms pull text from your page. They'll grab the first text they find — which might be your nav menu, cookie consent, or footer.

og:image

<meta property="og:image" content="https://example.com/images/deploy-guide-og.png" />

This is the most important tag. A link preview without an image gets significantly less engagement.

Rules:

Must be an absolute URL (not /images/og.png)
Recommended size: 1200x630px (1.91:1 ratio)
Minimum: 600x315px
Max file size: ~5MB (but keep it under 1MB for fast loading)
Use PNG or JPG (some platforms don't support WebP in OG images)

Common mistakes:

Using a relative URL — platforms can't resolve /images/og.png
Using your logo as the OG image — it looks tiny and generic in a preview card
Using an image that's too small — Facebook requires at least 200x200px
Using a CDN URL that requires authentication or returns 403

og:url

<meta property="og:url" content="https://example.com/blog/deploy-nodejs" />

The canonical URL for this page. Use this to consolidate shares across different URL variations (with/without trailing slash, with tracking params, etc.).

og:type

<meta property="og:type" content="article" />

Common values:

website — for homepages and general pages
article — for blog posts and news
product — for e-commerce
profile — for user profiles

Most sites should use website for the homepage and article for blog posts.

og:site_name

<meta property="og:site_name" content="MyBlog" />

Your brand name. Shown as secondary text in preview cards.

Twitter Card Tags

Twitter (X) uses its own meta tags, but falls back to OG tags if Twitter-specific ones are missing.

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="How to Deploy a Node.js App" />
<meta name="twitter:description" content="Step-by-step guide with PM2, Nginx, and SSL." />
<meta name="twitter:image" content="https://example.com/images/deploy-guide-og.png" />

The twitter:card value matters:

summary — small square image on the left, text on the right
summary_large_image — large image on top, text below (this is what you usually want)

Pro tip: If you set OG tags, you only need to add twitter:card. Twitter will use your OG title, description, and image as fallbacks.

<!-- Minimum Twitter setup if you already have OG tags -->
<meta name="twitter:card" content="summary_large_image" />

The Complete Template

Copy this into every page and fill in the values:

<!-- Open Graph -->
<meta property="og:title" content="Page Title Here" />
<meta property="og:description" content="A concise description under 160 chars." />
<meta property="og:image" content="https://example.com/images/page-og.png" />
<meta property="og:url" content="https://example.com/page" />
<meta property="og:type" content="website" />
<meta property="og:site_name" content="YourSiteName" />

<!-- Twitter -->
<meta name="twitter:card" content="summary_large_image" />

<!-- Standard HTML (don't skip these) -->
<title>Page Title Here | YourSiteName</title>
<meta name="description" content="A concise description under 160 chars." />
<link rel="canonical" href="https://example.com/page" />

How Each Platform Parses Your Tags

Different platforms handle OG tags differently:

Platform	Reads OG?	Reads Twitter Cards?	Image Size	Cache Duration
Facebook	Yes	No	1200x630	~24 hours
Twitter/X	Fallback	Yes (preferred)	1200x628	~7 days
LinkedIn	Yes	No	1200x627	~7 days
Slack	Yes	Fallback	1200x630	Varies
Discord	Yes	Fallback	Any	~minutes
iMessage	Yes	No	1200x630	~24 hours
WhatsApp	Yes	No	600x315+	~24 hours
Telegram	Yes	No	Any	~minutes

Key takeaway: If you set OG tags + twitter:card, you're covered everywhere.

Common Mistakes I See on Production Sites

1. Missing og:image

About 30-40% of pages I've tested have no og:image. Their links show up as plain text blocks in chat apps. Adding an image can increase click-through rates by 2-3x.

2. Relative image URLs

<!-- WRONG -->
<meta property="og:image" content="/images/og.png" />

<!-- RIGHT -->
<meta property="og:image" content="https://example.com/images/og.png" />

When Facebook's crawler sees /images/og.png, it doesn't know your domain. Always use absolute URLs.

3. Using the site logo as og:image

Your 200x200 logo looks terrible as a preview card image. Create a proper 1200x630 image for each page, or at least have a good default.

4. Description pulled from page content

If you don't set og:description, platforms will grab whatever text they find first. I've seen previews showing:

Cookie consent banners
Navigation menus
"Loading..." placeholder text
JavaScript error messages

5. Not testing after deployment

You deploy a new page, someone shares it, and the preview is broken. Always test your OG tags before announcing a launch.

How to Test Your OG Tags

Official Debuggers

Facebook: Sharing Debugger — paste URL, see preview, clear cache
Twitter: Card Validator — preview your Twitter card
LinkedIn: Post Inspector — check LinkedIn previews

API-Based Testing

If you need to check OG tags programmatically (e.g., in a CI pipeline or monitoring tool), you can use a metadata extraction API:

# Example: extract OG tags from any URL
curl "https://linkpeek-api.linkpeek.workers.dev/v1/demo?url=https://github.com"

This returns the parsed title, description, image, and favicon — useful for verifying your tags are correct without opening each platform's debugger manually.

Browser Extensions

Open Graph Preview (Chrome) — see OG tags on any page
Meta SEO Inspector — shows all meta tags in a panel

DIY with curl

curl -s https://example.com | grep -i 'og:' | head -10

Quick and dirty, but works for a spot check.

OG Tags for SPAs (React, Next.js, Vue)

Single-page apps are the #1 source of broken OG tags. Here's why: crawlers don't execute JavaScript. If your OG tags are set client-side, crawlers see an empty <head>.

Solutions

Next.js — use the built-in <Head> component or Metadata API:

// app/page.tsx (App Router)
export const metadata = {
  openGraph: {
    title: 'My Page',
    description: 'Page description',
    images: ['https://example.com/og.png'],
  },
};

Nuxt.js — use useHead:

useHead({
  meta: [
    { property: 'og:title', content: 'My Page' },
    { property: 'og:image', content: 'https://example.com/og.png' },
  ],
});

Plain React SPA — you need SSR or prerendering. Options:

Use react-helmet with a prerendering service
Switch to Next.js or Remix
Use a serverless function to serve the HTML shell with OG tags

Dynamic OG Images

The best OG images are generated dynamically — they include the page title, author, date, or other dynamic content.

Popular approaches:

Vercel OG (@vercel/og) — generates images at the edge using JSX
Satori — converts HTML/CSS to SVG (what Vercel OG uses under the hood)
Puppeteer/Playwright — screenshot an HTML template
Canvas API — programmatic image generation

Example with Vercel OG:

import { ImageResponse } from '@vercel/og';

export async function GET(request) {
  const { searchParams } = new URL(request.url);
  const title = searchParams.get('title') || 'My Site';

  return new ImageResponse(
    <div style={{ fontSize: 48, background: 'white', width: '100%', height: '100%', display: 'flex', alignItems: 'center', justifyContent: 'center' }}>
      {title}
    </div>,
    { width: 1200, height: 630 }
  );
}

Checklist

Before shipping any page:

[ ] og:title set and under 60 characters
[ ] og:description set and 120-160 characters
[ ] og:image is an absolute URL, 1200x630px, under 1MB
[ ] og:url matches your canonical URL
[ ] og:type is set (website or article)
[ ] twitter:card is set to summary_large_image
[ ] Tested on Facebook Sharing Debugger
[ ] Standard <title> and <meta description> also set
[ ] OG tags are server-rendered (not client-side only)

If you found this useful, I write about web dev and APIs regularly. Follow for more.

Free Alternatives to Microlink and OpenGraph.io in 2026

eatyou eatyou — Wed, 18 Mar 2026 02:19:09 +0000

Need an API to extract Open Graph metadata or generate link previews? Here's a comparison of the main options in 2026, including free alternatives that won't break the bank.

Why You Need a Link Preview API

If you're building any of these, you need link previews:

Chat apps (Slack-style URL unfurling)
Social feeds (rich link cards)
CMS / blog platforms (embed previews)
SEO tools (meta tag analysis)
Bookmarking apps

You could build your own scraper, but you'll quickly run into:

Handling JavaScript-rendered pages
Timeout and redirect chains
Character encoding issues
Rate limiting and caching
Maintenance overhead

An API handles all of this for you.

The Comparison

1. Microlink ($20-76/mo)

What it does: URL metadata extraction, screenshots, PDF generation, and more.

Pricing:

Free: 50 requests/day
Pro: $20/mo (10,000 req/mo)
Business: $76/mo (100,000 req/mo)

Pros: Feature-rich, good documentation, screenshot support
Cons: Expensive, limited free tier, complex pricing

2. OpenGraph.io ($12-79/mo)

What it does: Open Graph tag extraction, site info, and content scraping.

Pricing:

Free: 100 requests/month (not per day!)
Starter: $12/mo (10,000 req/mo)
Business: $79/mo (100,000 req/mo)

Pros: Simple API, reliable
Cons: Very limited free tier (100/month), no image generation

3. LinkPeek (Free — $9/mo)

What it does: URL metadata extraction + SVG preview card generation.

Pricing:

Free: 100 requests/day (3,000/month!)
Pro: $9/mo (5,000 req/day)
Business: $29/mo (50,000 req/day)

Pros:

Most generous free tier (100/day vs. competitors' 50/day or 100/month)
SVG preview cards — unique feature none of the others offer
Runs on Cloudflare's edge network (300+ PoPs, sub-50ms)
Simple email-only signup

Cons: No screenshot support yet (coming soon), newer service

Try it: linkpeek-api.linkpeek.workers.dev

4. DIY with Puppeteer/Playwright

What it does: Whatever you code it to do.

Pricing: Server costs ($5-50/mo for a VPS)

Pros: Full control, no API limits
Cons:

Maintenance headache
Memory-hungry (headless browsers eat RAM)
Cold start latency
You have to handle caching, rate limiting, error handling yourself

5. Open Source Libraries

Options:

open-graph-scraper (npm) — Node.js OG tag parser
link-preview-js (npm) — Client/server link preview
og-image (Vercel) — OG image generation (not extraction)

Pros: Free, self-hosted
Cons: You host and maintain it, no caching, no edge distribution

Quick Comparison Table

Feature	LinkPeek	Microlink	OpenGraph.io	DIY
Free tier	100/day	50/day	100/month	N/A
Pro price	$9/mo	$20/mo	$12/mo	$5-50/mo
SVG cards	Yes	No	No	Build it
Screenshots	Coming soon	Yes	No	Yes
Edge CDN	300+ PoPs	Limited	Limited	Your server
Setup time	10 seconds	Minutes	Minutes	Hours
Maintenance	Zero	Zero	Zero	Ongoing

Code Example: Switching from Microlink to LinkPeek

Before (Microlink):

const response = await fetch(
  `https://api.microlink.io/?url=${encodeURIComponent(url)}`,
  { headers: { 'x-api-key': MICROLINK_KEY } }
);
const { data } = await response.json();
// data.title, data.description, data.image.url

After (LinkPeek):

const response = await fetch(
  `https://linkpeek-api.linkpeek.workers.dev/v1/preview?url=${encodeURIComponent(url)}&key=${LINKPEEK_KEY}`
);
const data = await response.json();
// data.title, data.description, data.image

Almost identical API surface — migration takes minutes.

My Recommendation

For side projects and MVPs: Use LinkPeek's free tier (100 req/day is plenty)
For production apps needing screenshots: Microlink (until LinkPeek adds screenshot support)
For high-volume enterprise: Build your own with Puppeteer on dedicated infrastructure
For learning: Start with open-graph-scraper npm package

Getting Started with LinkPeek

# Get your free API key
curl -X POST https://linkpeek-api.linkpeek.workers.dev/v1/register \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

# Try it
curl "https://linkpeek-api.linkpeek.workers.dev/v1/preview?url=https://github.com&key=YOUR_KEY"

No credit card, no OAuth, no setup wizard. Email to API key to start building.

What link preview API are you using? Anything I missed? Let me know in the comments.

Add Rich Link Previews to Any Web App in 5 Minutes (React, Vue, Node.js)

eatyou eatyou — Wed, 18 Mar 2026 02:18:40 +0000

Every chat app, social feed, and CMS needs link previews. You paste a URL, and it shows the title, description, and image — like Slack, Discord, or Twitter.

Building this yourself means:

Fetching remote pages server-side
Parsing Open Graph / Twitter Card meta tags
Handling timeouts, redirects, encodings
Caching results
Running a headless browser if you want screenshots

Or you can use an API and skip all of that. Here's how to add link previews to your app in under 5 minutes using LinkPeek — a free link preview API.

Step 1: Get a Free API Key

curl -X POST https://linkpeek-api.linkpeek.workers.dev/v1/register \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

Response:

{
  "api_key": "lp_aBcDeFgHiJkLmNoPqRsTuVwXyZ012345",
  "plan": "free",
  "daily_limit": 100
}

Free tier: 100 requests/day, no credit card.

Step 2: Fetch Link Metadata

Node.js / Express

// server.js
app.get('/api/preview', async (req, res) => {
  const { url } = req.query;

  const response = await fetch(
    `https://linkpeek-api.linkpeek.workers.dev/v1/preview?url=${encodeURIComponent(url)}&key=${process.env.LINKPEEK_KEY}`
  );
  const data = await response.json();

  res.json(data);
  // Returns: { title, description, image, favicon, site_name, type }
});

Python / Flask

import requests

@app.route('/api/preview')
def preview():
    url = request.args.get('url')
    resp = requests.get(
        'https://linkpeek-api.linkpeek.workers.dev/v1/preview',
        params={'url': url, 'key': LINKPEEK_KEY}
    )
    return resp.json()

Step 3: Build the Preview Component

React

function LinkPreview({ url }) {
  const [preview, setPreview] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(`/api/preview?url=${encodeURIComponent(url)}`)
      .then(res => res.json())
      .then(data => { setPreview(data); setLoading(false); })
      .catch(() => setLoading(false));
  }, [url]);

  if (loading) return <div className="preview-skeleton" />;
  if (!preview) return null;

  return (
    <a href={url} className="link-preview" target="_blank" rel="noopener">
      {preview.image && <img src={preview.image} alt="" />}
      <div className="preview-text">
        <h4>{preview.title}</h4>
        <p>{preview.description}</p>
        <span className="preview-domain">
          {new URL(url).hostname}
        </span>
      </div>
    </a>
  );
}

CSS

.link-preview {
  display: flex;
  border: 1px solid #e5e7eb;
  border-radius: 12px;
  overflow: hidden;
  text-decoration: none;
  color: inherit;
  max-width: 500px;
  transition: box-shadow 0.2s;
}
.link-preview:hover {
  box-shadow: 0 4px 12px rgba(0,0,0,0.1);
}
.link-preview img {
  width: 120px;
  height: 120px;
  object-fit: cover;
}
.preview-text {
  padding: 12px 16px;
  flex: 1;
}
.preview-text h4 {
  font-size: 15px;
  margin: 0 0 4px;
  line-height: 1.3;
}
.preview-text p {
  font-size: 13px;
  color: #6b7280;
  margin: 0 0 8px;
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  overflow: hidden;
}
.preview-domain {
  font-size: 12px;
  color: #9ca3af;
}

Alternative: Embed SVG Cards (Zero JavaScript)

If you just need a preview image, skip the component entirely:

<img
  src="https://linkpeek-api.linkpeek.workers.dev/v1/preview/image?url=https://github.com&key=YOUR_KEY"
  alt="Link preview"
  width="600"
/>

This returns a styled SVG card — works in emails, READMEs, static sites, anywhere <img> tags work.

Step 4: Handle Edge Cases

function LinkPreview({ url }) {
  const [preview, setPreview] = useState(null);
  const [error, setError] = useState(false);

  useEffect(() => {
    const controller = new AbortController();

    fetch(`/api/preview?url=${encodeURIComponent(url)}`, {
      signal: controller.signal
    })
      .then(res => {
        if (!res.ok) throw new Error('Failed');
        return res.json();
      })
      .then(setPreview)
      .catch(err => {
        if (err.name !== 'AbortError') setError(true);
      });

    return () => controller.abort();
  }, [url]);

  if (error) return <a href={url}>{url}</a>;
  if (!preview) return <div className="preview-skeleton" />;

  return (/* same component as above */);
}

Key points:

Abort controller — cancel in-flight requests on unmount
Graceful fallback — show plain link if preview fails
Server-side proxy — never expose your API key in client code

Response Format

Every /v1/preview call returns:

{
  "url": "https://github.com",
  "title": "GitHub: Let's build from here",
  "description": "GitHub is where over 100 million developers...",
  "image": "https://github.githubassets.com/assets/social.png",
  "favicon": "https://github.githubassets.com/favicons/favicon.svg",
  "site_name": "GitHub",
  "type": "website"
}

Plus rate limit headers:

X-RateLimit-Limit — your daily limit
X-RateLimit-Remaining — requests left today
X-Cache — HIT or MISS

Pricing

Plan	Requests/day	Price
Free	100	$0
Pro	5,000	$9/mo
Business	50,000	$29/mo

For comparison, Microlink starts at $20/mo and OpenGraph.io at $12/mo.

Try It Now

LinkPeek: https://linkpeek-api.linkpeek.workers.dev

The landing page has a live demo — try any URL without signing up. No credit card, no setup friction.

Full API docs: https://linkpeek-api.linkpeek.workers.dev/docs

What are you building that needs link previews? I'd love to hear about your use case in the comments.

How I Built a Link Preview API on Cloudflare Workers for $0

eatyou eatyou — Tue, 17 Mar 2026 06:55:44 +0000

Adding link previews to a web app sounds simple until you actually try it. You need to:

Fetch the target URL
Parse HTML for Open Graph tags, meta tags, favicon
Handle timeouts, redirects, encoding issues
Optionally generate a visual preview card
Cache results so you're not hammering the same URLs

Most developers either self-host a scraper (hello, Puppeteer memory leaks) or pay $12-76/month for services like Microlink or OpenGraph.io.

I wanted something simpler. So I built LinkPeek — a link preview API that runs entirely on Cloudflare's free tier.

The Stack

Cloudflare Workers — serverless compute at the edge
Hono — lightweight web framework (Express-like but for Workers)
D1 — SQLite database for API keys, usage tracking, and caching

Total monthly cost: $0.

What It Does

1. Metadata Extraction

curl "https://linkpeek-api.linkpeek.workers.dev/v1/preview?url=https://github.com&key=YOUR_KEY"

Returns:

{
  "url": "https://github.com",
  "title": "GitHub: Let's build from here",
  "description": "GitHub is where over 100 million developers shape the future of software...",
  "image": "https://github.githubassets.com/assets/campaign-social.png",
  "favicon": "https://github.githubassets.com/favicons/favicon.svg",
  "site_name": "GitHub"
}

2. SVG Preview Cards

<img src="https://linkpeek-api.linkpeek.workers.dev/v1/preview/image?url=https://github.com&key=YOUR_KEY" />

Generates a styled SVG card with the site's metadata — ready to embed anywhere.

How the Metadata Extraction Works

The core logic fetches the target URL and parses the HTML response for:

Open Graph tags (og:title, og:description, og:image)
Twitter Card tags (twitter:title, twitter:description, twitter:image)
Standard meta tags (title, description, favicon)
Fallbacks (h1 tags, first paragraph, etc.)

Results are cached in D1 for 1 hour to avoid redundant fetches.

The SVG Card Generator

Instead of using headless browsers to render preview images (expensive!), I generate SVG cards server-side. SVGs are:

Lightweight (typically under 5KB)
Resolution-independent
Easily styled
Cacheable

Security

A few things I built in:

SSRF Protection — blocks requests to localhost, private IPs
Rate Limiting — 100 req/day free, with X-RateLimit-* headers
HTML Size Limit — responses capped at 1MB
Register Rate Limit — max 5 per IP per hour

API Endpoints

Endpoint	Description
`POST /v1/register`	Get free API key
`GET /v1/preview?url=`	JSON metadata
`GET /v1/preview/image?url=`	SVG preview card
`GET /v1/usage`	Usage stats
`GET /docs`	Full API docs

Getting Started

curl -X POST https://linkpeek-api.linkpeek.workers.dev/v1/register \n  -H "Content-Type: application/json" \n  -d '{"email": "you@example.com"}'

Then start making requests — 100/day free.

What's Next

PNG screenshots — URL-to-image rendering
Custom card templates — user-styled preview cards
Higher rate limits — paid tiers at $9/mo and $29/mo

Try It

LinkPeek: https://linkpeek-api.linkpeek.workers.dev

Docs: https://linkpeek-api.linkpeek.workers.dev/docs

Free tier, no credit card needed. Would love your feedback!

Built with Cloudflare Workers, Hono, and D1.

DEV Community: eatyou eatyou

How to Add Link Previews to Your React App (With Code Examples)

Why Link Previews Are Tricky

Approach 1: Build Your Own Backend Proxy

The Problems With DIY

Approach 2: Use a Link Preview API

Handling Multiple URLs

Summary

How I Built a Website Health Scanner Inside Cloudflare Workers (And the Constraints I Hit)

The Stack

Constraint #1: No DOM API

Constraint #2: CPU Time Limits

Constraint #3: Scoring Across Different Severity Levels

What the Scanner Actually Checks

Interesting Edge Cases

The Result

"Debugging Open Graph Tags: Why Your Link Previews Look Wrong"

Step 1: Check if Your Tags Are Actually in the HTML

Step 2: The JavaScript Rendering Problem

Step 3: Platform Cache Is Showing Old Data

Step 4: Check Your Image URL

Step 5: Encoding and Special Characters

Step 6: Duplicate Tags

Step 7: The og:url Mismatch

A Debugging Script

Tools That Do This For You

Summary Checklist

Twitter Cards vs Open Graph: What's the Difference and Which Should You Use?

The Short Answer

Open Graph Protocol

Image Requirements for Open Graph

Twitter Cards

Summary Card (default)

Summary Card with Large Image

App Card

Player Card

How Twitter Falls Back to Open Graph

The Complete Template

Common Mistakes

Platform Debugging Tools

Dynamic OG Images

Summary

The Developer's Pre-Launch Checklist: 40 Things to Check Before Shipping

Performance

SEO & Social Sharing

Security

Accessibility

Error Handling

Mobile

Monitoring & Analytics

Launch Day

The Meta-Checklist

Tools I Use for Each Category

Print It, Pin It

Building a Favicon Finder: Why It's Harder Than You Think

The Naive Approach

The Problem: There's No Single Standard

1. The Original: /favicon.ico

2. HTML Link Tags (Many Variants)

3. Web App Manifest

4. Microsoft browserconfig.xml

The Algorithm That Works

Edge Cases That Will Ruin Your Day

1. Data URIs as Favicons

2. Relative Paths with Subdirectories

3. Protocol-Relative URLs

4. Multiple Favicons for Different Purposes

5. favicon.ico That Returns HTML

6. CDN-Hosted Favicons with CORS Issues

Google's Favicon API: The Lazy (Smart) Option

DuckDuckGo's Alternative

Testing Your Implementation

Recap

Web Scraping Meta Tags Without Getting Blocked — Lessons Learned

The Simple Version (That Breaks Immediately)

Problem 1: Bot Detection

What Gets You Blocked

What Works

Rate Limiting Yourself

Problem 2: Redirect Chains

Step 7: The `og:url` Mismatch