DEV Community: Ravi Kumar

I Built a Social Card Validator in a Weekend (and Here's What I Learned About Open Graph Tags)

Ravi Kumar — Mon, 09 Feb 2026 21:06:09 +0000

TL;DR: I shipped LinkPreview.io - a tool that shows how your URL looks when shared on 6 social platforms. No signup, no BS, just paste a URL and see all your preview cards + get a scored list of fixes.

The "Ugh, Not Again" Moment

You know that feeling when you share your blog post on Twitter, and instead of your beautiful featured image, it shows... nothing? Or worse, a random screenshot from halfway down the article?

I had this happen with my podcast episode pages. Everything looked fine when I tested locally. The og:image tag was there in the HTML. But Twitter refused to show the image. I spent 30 minutes jumping between:

Twitter Card Validator (which required me to log in)
Facebook Sharing Debugger (different login)
LinkedIn Post Inspector (another login)
Manually sharing to Slack to see what happened

Each tool showed me slightly different data. Each one required authentication. And none of them showed me what my link would actually look like in the feed.

I thought: "There has to be a better way."

Narrator: There wasn't.

So I built one.

What I Built

LinkPreview.io - Paste any URL, see instant previews for:

Twitter/X (both large image + compact cards)
Facebook (both large + link preview cards)
LinkedIn
Slack
Discord
Google Search (standard + rich result)

Plus, it scores your meta tags 0-100 and gives you actionable fixes with copy-paste code snippets.

🔗 Try it: linkpreview.io

The Tech Stack (and Why)

SvelteKit - I chose Svelte 5 (with runes) because:

The preview cards need instant reactivity when meta tags change
I wanted a tiny bundle size (<30KB gzipped)
Svelte's fine-grained reactivity made state management trivial

Cloudflare Pages - Edge deployment, zero config, serverless API routes. I can deploy with git push. It's beautiful.

Cheerio - Server-side HTML parsing. Lighter than Puppeteer, perfect for extracting <meta> tags.

Tailwind v4 - Dark mode first, utility-first, fast.

The Hard Parts

1. SSRF Protection (Or: How I Almost Built an IP Scanner)

The core feature is: user pastes a URL, my server fetches it, extracts meta tags, returns JSON.

Simple, right?

Wrong.

If I just do fetch(userUrl), an attacker can:

Point me at internal IPs: http://192.168.1.1
Exfiltrate cloud metadata: http://169.254.169.254/latest/meta-data/
Use my server to port-scan: http://internal-admin-panel:8080

My solution:

import { isPrivateIp } from './ssrf-protection.js';

async function safeFetch(url) {
  // 1. Parse and validate URL
  const parsed = new URL(url);

  // 2. Pre-redirect IP check
  const ip = await dns.resolve(parsed.hostname);
  if (isPrivateIp(ip)) {
    throw new Error('Private IP addresses are not allowed');
  }

  // 3. Fetch with redirect: 'manual' so we can check each hop
  let response = await fetch(url, { redirect: 'manual' });

  // 4. Follow redirects manually, checking each destination IP
  while (response.status >= 300 && response.status < 400) {
    const location = response.headers.get('location');
    const redirectIp = await dns.resolve(new URL(location).hostname);
    if (isPrivateIp(redirectIp)) {
      throw new Error('Redirect to private IP blocked');
    }
    response = await fetch(location, { redirect: 'manual' });
  }

  return response;
}

The trick: even if the initial URL is public, a redirect can send you to a private IP. You have to check every hop.

I also added:

Response size cap (5MB max)
Timeout (10 seconds)
Rate limiting (10 req/min per IP)
Cloud metadata endpoint blocking (169.254.169.254, metadata.google.internal, etc.)

2. Character Truncation is a Nightmare

Every platform truncates titles and descriptions at different lengths:

Platform	Title Limit	Description Limit
Twitter	70 chars	200 chars
Facebook	~100 chars	~300 chars
Google	60 chars	160 chars
LinkedIn	120 chars	~150 chars
Slack	No limit	~150 chars
Discord	No limit	~200 chars

These are all undocumented and vary by context (e.g., Twitter timeline vs. DMs).

I built visual truncation bars:

<script>
  let titleLength = $derived(metaTags.title?.length || 0);
  let twitterLimit = 70;
  let truncationPercent = $derived((titleLength / twitterLimit) * 100);
  let isOverLimit = $derived(titleLength > twitterLimit);
</script>

<div class="truncation-bar">
  <div 
    class="fill"
    class:red={isOverLimit}
    style="width: {Math.min(truncationPercent, 100)}%"
  />
  <span>{titleLength}/{twitterLimit}</span>
</div>

The bar turns red when you're over the limit. Simple, but effective.

3. Recommendation Scoring is Subjective

How do you score meta tags? I built a weighted system:

Critical issues (20 points each):

Missing og:title
Missing og:image
Image too small (<1200x627)

Major issues (10 points each):

Missing og:description
Title too long (>60 chars)
Image aspect ratio off

Minor issues (5 points each):

Missing twitter:card
Title has site name at the end ("My Post | MySite.com")
Description too short (<50 chars)

Start at 100, subtract points for each issue. Simple, transparent, and users immediately understand "52/100" means "you need to fix stuff."

4. Why Svelte 5 Runes Are Amazing

Old Svelte:

<script>
  let count = 0;
  $: doubled = count * 2;
</script>

New Svelte (runes):

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

The $derived rune is so much clearer than $:. It reads like: "this value is derived from that state." No magic, no confusion.

For this project, every preview card is a derived value:

let twitterCard = $derived({
  title: metaTags['twitter:title'] || metaTags['og:title'] || metaTags.title,
  description: metaTags['twitter:description'] || metaTags['og:description'],
  image: metaTags['twitter:image'] || metaTags['og:image'],
  card: metaTags['twitter:card'] || 'summary_large_image'
});

Reactivity just works. Change one meta tag, all 6 platform cards update instantly.

What I Learned About Open Graph

1. Most CMSs get it wrong by default

WordPress, Ghost, Wix - they all generate og:image thumbnails that are too small. The default is usually 800x600, but:

Twitter recommends 1200x675 (2:1 ratio)
Facebook recommends 1200x630 (1.91:1 ratio)
LinkedIn requires 1200x627 minimum

If your image is too small, platforms either don't show it or stretch it to look terrible.

2. Twitter cards fallback to Open Graph, but inconsistently

Twitter usually falls back to og:title if twitter:title is missing. But not always. Sometimes it uses the <title> tag. Sometimes it just shows the URL.

The safe bet: always set both og:* and twitter:* tags explicitly.

3. Google doesn't care about Open Graph

Google Search ignores og:title and og:description completely. It uses:

<title> tag (truncates at 60 chars)
<meta name="description"> (truncates at 160 chars)

But if you have JSON-LD structured data, Google prefers that over meta tags. So now you need three sets of metadata.

4. Facebook's debugger lies

Facebook Sharing Debugger shows you a cached version of your page. Even if you update your meta tags, the debugger still shows the old version until you click "Scrape Again."

I've seen developers waste hours debugging a non-existent problem because they didn't know about the cache.

Mistakes I Made

1. I almost over-engineered the database

My original plan: store every URL validation in Cloudflare D1, let users create accounts, save history, etc.

Then I thought: "Why? What value does that add in Phase 1?"

Answer: None.

So I made it stateless. The server extracts tags, returns JSON, forgets everything. No database, no user accounts, no complexity. You can still share results via URL params (linkpreview.io?url=example.com).

Ship the simplest version that solves the problem.

2. I spent too long on visual polish

I wasted 2 hours tweaking the box shadow on the preview cards. Does it matter? No. Does it feel better? Yes.

But here's the thing: users don't care about your box shadow. They care about whether your tool solves their problem. Polish matters, but not as much as functionality.

Ship fast, polish later.

3. I didn't validate my assumptions

I assumed people wanted side-by-side comparison (test staging vs. production URLs). So I built a whole UI for it.

Then I realized: nobody asked for this. It's a Phase 2 feature at best.

I cut it. Saved myself 4 hours.

Validate demand before building features.

What's Next?

This is Phase 1. I kept it intentionally minimal to ship fast. Phase 2 ideas:

Bulk validation - Upload a CSV, validate 100 URLs at once
Scheduled monitoring - Alert me if my preview changes
API access - Integrate into CI/CD pipelines
Chrome extension - Right-click any page → validate

Pricing model: freemium. Free for single URLs, paid for bulk/monitoring/API.

Try It

🔗 linkpreview.io

Source code (coming soon): https://github.com/ravichosun/LinkPreview

Built with:

SvelteKit (Svelte 5)
Tailwind CSS v4
Cloudflare Pages
Cheerio

Total build time: ~1 weekend + polish

Total lines of code: ~8,000

Client bundle size: <30KB gzipped

Lessons Learned

Ship fast, validate demand - Don't build Phase 2 features until Phase 1 proves valuable
SSRF protection is non-negotiable - If you're fetching user URLs, validate every redirect hop
Svelte 5 runes are incredible - Derived state makes reactive UIs trivial
Open Graph is a mess - Every platform interprets tags differently; test everything
Stateless > stateful - No database = faster, simpler, cheaper

If you've ever shared a link on social media and been frustrated by broken previews, give LinkPreview.io a try. And if you find bugs (you will), let me know in the comments!

Happy shipping 🚀

I Built a Timestamp Converter That Doesn't Suck (And It's Free)

Ravi Kumar — Sat, 31 Jan 2026 19:58:31 +0000

How many times have you been debugging API logs, staring at 1706745600, and thought "What date is this even?"

You Google "unix timestamp converter," click the first result, and get hit with:

Three banner ads
A dropdown to select "Unix timestamp (seconds)"
Another dropdown to select output format
More ads
Oh, and it wants you to sign up

I got tired of this. So over a weekend, I built TimeStampConverter.net - a timestamp converter that just works.

What Makes It Different?

Auto-Detection

Paste anything. The tool figures out if it's:

Unix timestamp (seconds): 1706745600
Unix timestamp (milliseconds): 1706745600000
ISO 8601: 2024-01-31T12:00:00Z
RFC 2822: Thu, 31 Jan 2024 12:00:00 GMT
Human readable: January 31, 2024

No dropdowns. No clicking. It just knows.

One Paste, Seven Formats

One paste shows all these formats simultaneously:

Unix (seconds):     1706745600
Unix (ms):          1706745600000
ISO 8601 (UTC):     2024-01-31T17:00:00.000Z
ISO 8601 (Local):   2024-01-31T12:00:00.000-05:00
RFC 2822:           Wed, 31 Jan 2024 12:00:00 -0500
Human:              January 31, 2024 12:00:00 PM
Relative:           2 hours ago

Each has a copy button. Click once, paste into your code.

400+ Timezones

Searchable timezone dropdown. Type "Tokyo" and it jumps there. Convert to any timezone instantly.

Date Math Built-In

Need to know what timestamp is "30 days from now"? There's a calculator for that:

Add/subtract: years, months, days, hours, minutes, seconds
Duration between two timestamps
Handles DST and leap years correctly

Bulk Conversion

Paste multiple timestamps (one per line), convert them all at once. Perfect for log analysis.

URL Sharing

Share specific timestamps: https://timestampconverter.net?ts=1706745600

Dark Mode by Default

Because you're probably using this at 2 AM debugging prod issues.

Zero Tracking

No analytics. No ads. No signup. No cookies. Everything runs client-side.

The Tech Stack

I kept it brutally simple:

// That's it. That's the whole dependency list.
{
  "dependencies": {
    "dayjs": "^1.11.10"
  }
}

Vanilla JavaScript - No React, no Vue, no build step
day.js - Lightweight date library (~2KB)
Cloudflare Pages - Free hosting with global CDN
Total bundle size: ~50KB

Why Vanilla JS?

I know what you're thinking: "Nobody uses vanilla JS anymore!"

But here's the thing - this app:

Doesn't need state management
Doesn't need routing
Doesn't need a virtual DOM
Needs to load fast

A React app with similar functionality would be 200KB+. This loads in under 100ms anywhere in the world.

How Auto-Detection Works

The secret sauce is a simple regex-based detection:

function detectTimestampFormat(input) {
  const trimmed = input.trim();

  // Unix timestamp (10 digits = seconds)
  if (/^\d{10}$/.test(trimmed)) {
    return { type: 'unix-seconds', value: parseInt(trimmed) };
  }

  // Unix timestamp (13 digits = milliseconds)
  if (/^\d{13}$/.test(trimmed)) {
    return { type: 'unix-ms', value: parseInt(trimmed) };
  }

  // ISO 8601 (starts with YYYY-MM-DDT)
  if (/^\d{4}-\d{2}-\d{2}T/.test(trimmed)) {
    return { type: 'iso8601', value: trimmed };
  }

  // RFC 2822 (starts with day name)
  if (/^[A-Za-z]{3},\s\d{2}\s[A-Za-z]{3}\s\d{4}/.test(trimmed)) {
    return { type: 'rfc2822', value: trimmed };
  }

  // Try generic date parsing
  const parsed = dayjs(trimmed);
  if (parsed.isValid()) {
    return { type: 'generic', value: trimmed };
  }

  return { type: 'invalid', value: null };
}

Once detected, converting is trivial with day.js:

function convertTimestamp(detected) {
  let date;

  switch(detected.type) {
    case 'unix-seconds':
      date = dayjs.unix(detected.value);
      break;
    case 'unix-ms':
      date = dayjs(detected.value);
      break;
    default:
      date = dayjs(detected.value);
  }

  return {
    unixSeconds: date.unix(),
    unixMs: date.valueOf(),
    iso8601UTC: date.utc().format(),
    iso8601Local: date.format(),
    rfc2822: date.format('ddd, DD MMM YYYY HH:mm:ss ZZ'),
    humanReadable: date.format('MMMM D, YYYY h:mm:ss A'),
    relative: date.fromNow()
  };
}

Deployment on Cloudflare Pages

This was the easiest part:

# 1. Build (or just use raw files)
# (nothing to build for vanilla JS!)

# 2. Deploy
wrangler pages deploy . --project-name=timestamp

# Done. Live globally in ~30 seconds.

Cloudflare gives you:

Unlimited bandwidth (actually unlimited on free tier)
300+ edge locations
Automatic HTTPS
Preview deployments for every git push
Built-in analytics

All for $0/month.

What I Learned

1. Sometimes Vanilla JS is the Right Choice

Not everything needs a framework. For small utilities, vanilla JS + a tiny library can beat any framework on performance.

2. Auto-Detection is Magical UX

Users love tools that "just work." No configuration, no dropdowns, just paste and go.

3. Dark Mode Should Be Default

Especially for dev tools. We're often using these at night or in dark IDEs.

4. Cloudflare Pages is Underrated

Vercel and Netlify get all the love, but Cloudflare's free tier is genuinely unlimited and faster for global users.

5. Solve Your Own Problem

I built this because I was frustrated. Now I use it 20+ times a day. That's validation enough.

What's Next?

Some features I'm considering:

Browser extension (right-click timestamp → convert)
API endpoint for programmatic access
Cron expression validator
ISO week number calculator

But honestly? The tool does what I need. I might just leave it as-is.

Try It Yourself

TimeStampConverter.net

No signup, no tracking, no BS. Just timestamps.

If you find it useful, bookmark it. That's all I ask.

FAQ

Q: Is this open source?

A: Not yet, but I'm considering it. If there's interest, I'll put it on GitHub.

Q: How do you make money from this?

A: I don't. It costs $0/month to run. Maybe I'll add a "buy me a coffee" button someday.

Q: Can I use this for my app/API?

A: Everything runs client-side, so yeah, go nuts. If you need an API endpoint for server-side conversions, let me know - I might build one.

Q: What about privacy?

A: All conversions happen in your browser. I literally cannot see what you're converting. Cloudflare logs basic CDN metrics (requests per region, bandwidth) but no user data.

Q: Can you add features?

A: Maybe! Drop a comment below or email me through the site.

JSON Diff Tool

Ravi Kumar — Fri, 30 Jan 2026 17:26:36 +0000

Quick tool announcement: I built a browser-based JSON diff tool because I didn't like how the current options were cluttered with ads and didn't have the features I wanted.

What makes it different?

Client-side only - Your JSON never touches a server. Everything runs in your browser.

Shareable links - Generate URLs with the diff encoded directly in them. No database, no expiration.

Dead simple - Paste two JSON docs, see the differences. That's it.

Actually free - No freemium model, no "upgrade to compare larger files", just free.

When I use it:

Comparing API responses while debugging
Checking what changed in config files
Sharing diffs with teammates (just send the URL!)
Verifying test data structures

Link

https://jsondifference.com/

Try it out and let me know what you think! Open to feature suggestions.

DEV Community: Ravi Kumar

I Built a Social Card Validator in a Weekend (and Here's What I Learned About Open Graph Tags)

The "Ugh, Not Again" Moment

What I Built

The Tech Stack (and Why)

The Hard Parts

1. SSRF Protection (Or: How I Almost Built an IP Scanner)

2. Character Truncation is a Nightmare

3. Recommendation Scoring is Subjective

4. Why Svelte 5 Runes Are Amazing

What I Learned About Open Graph

Mistakes I Made

What's Next?

Try It

Lessons Learned

I Built a Timestamp Converter That Doesn't Suck (And It's Free)

What Makes It Different?

Auto-Detection

One Paste, Seven Formats

400+ Timezones

Date Math Built-In

Bulk Conversion

URL Sharing

Dark Mode by Default

Zero Tracking

The Tech Stack

Why Vanilla JS?

How Auto-Detection Works

Deployment on Cloudflare Pages

What I Learned

1. Sometimes Vanilla JS is the Right Choice

2. Auto-Detection is Magical UX

3. Dark Mode Should Be Default

4. Cloudflare Pages is Underrated

5. Solve Your Own Problem

What's Next?

Try It Yourself

FAQ

JSON Diff Tool

What makes it different?

When I use it:

Link

DevTools #WebDev