DEV Community: Corbanware

I Built a Free OG Image API -- Here's What I Learned

Corbanware — Mon, 18 May 2026 01:01:25 +0000

I Built a Free OG Image API -- Here's What I Learned

Six weeks ago, I was in Figma at 11 PM on a Tuesday, designing my fourteenth OG image of the week. Same process as always: create a 1200x630 canvas, add a gradient background, type the blog post title, adjust the font size until it fits, export as PNG, upload to my project, update the meta tags. Fifteen minutes per image. Fourteen images. Three and a half hours of my life that week, doing something a computer should be doing.

That was the moment I decided to build ogimg.xyz.

The Problem That Would Not Go Away

I am a solo developer building a portfolio of small SaaS tools. Every product I ship needs a landing page. Every landing page needs OG images. Every blog post needs an OG image. Every documentation page needs one too.

At first, I used Figma templates. It worked for the first 10 images. By image 30, I was cutting corners. By image 50, I was skipping OG images entirely.

I looked at existing solutions:

Headless browser screenshot services -- Slow (1-3 seconds per image) and expensive to run at scale.
Design tool APIs -- Pricing starts at $40-50/month. Hard to justify for a solo dev with no revenue.
@vercel/og -- Excellent, but I did not want to build template code in every project. I wanted a single API.

None of these hit the sweet spot: fast, cheap (ideally free for small usage), and an API callable from any project.

The Technical Decisions

Vercel Edge, Not a Server

The single most important decision was running on Vercel Edge Functions instead of a traditional server. Edge functions execute on Cloudflare's network, close to the user, with near-zero cold starts.

The result: most requests complete in 200-500ms. Fast enough to use as a dynamic og:image URL.

No Headless Browser

I used Satori, Vercel's library that converts React JSX directly to SVG. The SVG then gets rasterized to PNG via Resvg, a Rust-based SVG renderer compiled to WebAssembly.

The pipeline: JSX -> SVG -> PNG. No browser. No DOM. 100-200ms total.

The tradeoff? Limited CSS subset. No position: absolute. No box-shadow. No CSS Grid. Everything Flexbox. This constraint turned out to be a feature -- it forced simpler, cleaner templates.

Template-Based, Not Freeform

I chose curated templates over arbitrary HTML/CSS:

Performance. Pre-built templates mean predictable rendering.
Quality floor. Every image looks decent by default.
Simplicity. Users send template=gradient instead of writing JSX.

10 templates covering gradient backgrounds, minimal text, bold hero-style, documentation, corporate, retro, and more. Each supports 10 background patterns (dots, grid, diagonal lines, waves, hexagons, etc.).

What Surprised Me

Simplicity Wins, Every Time

My initial version had 25 configurable parameters. Nobody used most of them. I stripped it down to about 10 that actually matter: title, description, template, pattern, background color, text color, accent color, site name, author, and logo. Usage immediately went up.

Free Tier Drives Adoption

I offer a free tier: 50 images per month, 4 templates. No credit card required.

Developers are allergic to entering payment information before evaluating a tool. The free tier lets people integrate, see it working, then decide to upgrade.

Edge Rendering Is the Right Architecture

OG images are generated when a social platform's crawler visits a URL. That crawler could be anywhere geographically. Edge rendering means the image is generated at the nearest PoP, so a Facebook crawler in Ireland does not wait for a round trip to us-east-1.

The Honest Numbers

Development time: About 6 weeks, nights and weekends
Infrastructure cost: Effectively $0/month. Vercel free tier + Neon PostgreSQL free tier.
Revenue: Early days. A few paid users on Hobby ($4.90/month). One lifetime purchase ($149).

This is product number one in a larger portfolio. The goal was to build something useful, learn the full stack of launching a SaaS, and have a tool I genuinely use myself.

What I Would Do Differently

Ship the MVP faster. I spent too long polishing templates before launch.
Build the visual playground earlier. The interactive playground turned out to be the primary way people discover the product.
Write integration guides from the start. Developers search for 'Next.js OG images', not 'OG image generation API'.

Try It

If any of this resonates, give ogimg.xyz a try. Free tier, no credit card:

curl "https://ogimg.xyz/api/og?title=Hello+World&template=gradient"&utm_source=devto&utm_medium=article&utm_campaign=wf5 --output og-image.png

Or visit the site and use the visual playground to design something, then copy the URL for your og:image meta tag.

I am building this in public as a solo developer. If you have feedback, I genuinely want to hear it. Drop a comment below.

Thanks for reading. Now go add OG images to that side project you have been meaning to polish.

If you found this interesting, consider leaving a reaction. Building in public is more fun when people are actually watching.

OG Image Sizes: The Complete Guide for 2026

Corbanware — Mon, 11 May 2026 01:00:58 +0000

OG Image Sizes: The Complete Guide for 2026

Here is the quick answer: 1200 x 630 pixels. If you remember nothing else from this article, remember that number. It works on every major platform without cropping or distortion.

But if you want to understand why, what the edge cases are, and how to avoid the mistakes that make your shared links look broken, keep reading.

Quick Reference Table

Platform	Recommended Size	Min Size	Aspect Ratio	Max File Size
Facebook	1200 x 630	600 x 315	1.91:1	8 MB
Twitter/X (large card)	1200 x 628	300 x 157	2:1	5 MB
Twitter/X (summary)	240 x 240	144 x 144	1:1	5 MB
LinkedIn	1200 x 627	200 x 200	1.91:1	5 MB
Slack	1200 x 630	Any	1.91:1	No hard limit
Discord	1200 x 630	Any	1.91:1	8 MB
WhatsApp	1200 x 630	300 x 200	1.91:1	5 MB
iMessage	1200 x 630	Any	1.91:1	No hard limit
Pinterest	1200 x 630	200 x 200	1.91:1	10 MB

Bookmark this table. Reference it when you need it.

Why 1200 x 630 Is the Standard

Back in 2010, Facebook introduced the Open Graph protocol to let websites control how shared links appear in the News Feed. They settled on a roughly 1.91:1 aspect ratio for link preview images. Every other platform that came along afterward -- Twitter, LinkedIn, Slack, Discord -- adopted the same ratio or something close enough that a 1200x630 image displays without issues.

The result: one image at 1200 x 630 works everywhere. You do not need platform-specific images. Period.

Why 1200px wide specifically? Because it renders crisply on high-DPI (Retina) displays. On a standard feed where link cards are displayed at around 600px wide, a 1200px source image means 2x pixel density. Your text stays sharp, your gradients stay smooth.

PNG vs. JPEG: Which Format to Use

PNG -- Use for images with text, solid colors, or sharp edges. Most OG images fall into this category.
JPEG -- Use for photographic images. JPEG compresses these more efficiently.
WebP -- Inconsistent support across platforms. Stick to PNG or JPEG.
SVG -- Do not use SVG for OG images. Most platforms will silently ignore it.

The Safe Zone: Where to Place Your Content

Platforms do not all crop identically. Keep all important content within a 60px margin safe zone on all sides. That means your actual content area is roughly 1080 x 510 pixels.

Font Size Matters More Than You Think

OG images are typically displayed at 400-600 pixels wide in feeds. Rules of thumb:

Title text: Minimum 48px at 1200px width
Description text: Minimum 28px at 1200px width
Limit text to 2-3 lines for the title
High contrast: White text on dark backgrounds or vice versa

Common Mistakes (and How to Fix Them)

1. Using a square image -- A 1:1 image will get aggressively cropped. Always use 1200 x 630.

2. File size too large -- Aim for under 1 MB. Use TinyPNG or ImageOptim to compress.

3. Relative URLs in the meta tag -- Social platform crawlers need the full absolute URL starting with https://.

4. Caching issues -- Platforms cache OG images aggressively. Use each platform's debugger tool to bust the cache.

5. Missing width and height meta tags -- Providing og:image:width and og:image:height helps platforms render previews faster.

How to Test Your OG Images

Facebook Sharing Debugger -- Paste your URL, click Scrape Again
Twitter Card Validator -- Preview the card rendering
LinkedIn Post Inspector -- Check LinkedIn's cache
opengraph.xyz -- Previews across multiple platforms simultaneously

Automating OG Image Generation

For sites with many pages, manual OG image creation does not scale. Options:

@vercel/og -- JSX to PNG on the edge. Free, self-hosted.
Cloudinary -- Text overlay capabilities for dynamic transformations.
ogimg.xyz -- Dedicated API for OG image generation. Free tier with 50 images/month.
Puppeteer/Playwright -- Screenshot approach. Flexible but slow.

The One-Sentence Summary

Use 1200 x 630 pixels, PNG format, under 1 MB, with text inside a 60px safe zone, and always test with platform debugger tools before you ship.

Found this useful? Follow me for more practical web development guides.

How to Add OG Images to Next.js in 5 Minutes

Corbanware — Mon, 27 Apr 2026 01:01:38 +0000

How to Add OG Images to Next.js in 5 Minutes

If you have ever shared a link on Twitter or Slack and watched it render as a sad, plain-text URL with no preview image, you already understand why OG images matter. Those 1200x630 pixel cards are the difference between a link that gets clicked and one that gets scrolled past. Studies show that links with rich preview images get 2-3x more engagement than bare text links.

The good news: if you are building with Next.js and the App Router, adding OG images is remarkably straightforward. Let me walk you through three approaches, from the simplest to the most powerful.

The Foundation: Understanding OG Meta Tags

Before we touch any Next.js code, here is what the browser needs to see in your HTML <head>:

<meta property="og:image" content="https://yoursite.com/og.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:title" content="Your Page Title" />
<meta property="og:description" content="A brief description" />

That is it. Every social platform (Facebook, Twitter/X, LinkedIn, Slack, Discord, WhatsApp) reads these tags to build the preview card. The image URL must be absolute -- relative paths will not work.

Approach 1: Static Metadata (30 Seconds)

For pages where the OG image never changes (your homepage, about page, pricing page), use the metadata export in your layout or page file:

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "My Awesome App",
  description: "The best thing since sliced bread",
  openGraph: {
    title: "My Awesome App",
    description: "The best thing since sliced bread",
    images: [
      {
        url: "https://yoursite.com/og-homepage.png",
        width: 1200,
        height: 630,
        alt: "My Awesome App - homepage preview",
      },
    ],
  },
  twitter: {
    card: "summary_large_image",
  },
};

Next.js automatically renders the correct <meta> tags in the HTML head. No manual string concatenation, no dangerouslySetInnerHTML. It even handles the Twitter card fallback for you.

Pro tip: Always include the twitter.card: "summary_large_image" property. Without it, Twitter defaults to the small square card, which wastes most of your carefully designed image.

Approach 2: Dynamic generateMetadata (2 Minutes)

This is where things get interesting. For blogs, documentation, or any page with dynamic content, you want a unique OG image per page. The generateMetadata async function lets you compute metadata at request time:

// app/blog/[slug]/page.tsx
import type { Metadata } from "next";
import { getPostBySlug } from "@/lib/posts";

interface Props {
  params: Promise<{ slug: string }>;
}

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  const post = await getPostBySlug(slug);

  if (!post) return {};

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      type: "article",
      publishedTime: post.publishedAt,
      images: [
        {
          url: `https://yoursite.com/api/og?title=${encodeURIComponent(post.title)}`,
          width: 1200,
          height: 630,
        },
      ],
    },
    twitter: { card: "summary_large_image" },
  };
}

Notice the OG image URL points to an API route. That brings us to the next question: how do you actually generate the image?

Approach 3: Generating Images on the Fly

You have two main options here.

Option A: @vercel/og (Self-Hosted)

Vercel's @vercel/og library lets you write JSX that renders as an image. It uses Satori under the hood -- a layout engine that converts React components to SVG, then rasterizes to PNG.

// app/api/og/route.tsx
import { ImageResponse } from "next/og";

export const runtime = "edge";

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const title = searchParams.get("title") ?? "My Blog";

  return new ImageResponse(
    <div style={{ width: '100%', height: '100%', display: 'flex', flexDirection: 'column', justifyContent: 'center', alignItems: 'center', background: 'linear-gradient(135deg, #667eea 0%, #764ba2 100%)', color: 'white', padding: 60 }}>
      <h1 style={{ fontSize: 64, fontWeight: 700, textAlign: 'center' }}>{title}</h1>
    </div>,
    { width: 1200, height: 630 }
  );
}

This works well if you want full control over the design and are comfortable with Satori's CSS limitations.

Option B: External API

If you would rather not maintain your own image generation endpoint, an external API simplifies things significantly. For example, with ogimg.xyz, your dynamic metadata becomes:

const ogUrl = new URL("https://ogimg.xyz/api/og"?utm_source=devto&utm_medium=article&utm_campaign=wf5);
ogUrl.searchParams.set("title", post.title);
ogUrl.searchParams.set("description", post.excerpt);
ogUrl.searchParams.set("template", "gradient");

No API route to maintain, no font files to bundle, no Satori quirks to debug. ogimg.xyz offers a free tier of 50 images/month, which is enough for most personal blogs and small projects.

Testing Your OG Images

After deploying, always verify your images actually work:

Facebook Sharing Debugger -- Paste your URL and hit Scrape Again to force a fresh fetch.
Twitter Card Validator -- Preview exactly what Twitter will render.
LinkedIn Post Inspector -- Check how LinkedIn will render your shared link.
Open your browser DevTools -- Search the HTML head for og:image and make sure the URL loads.

Quick Checklist

og:image URL is absolute (starts with https://)
Image dimensions are 1200x630
File size is under 1MB (5MB max for most platforms)
twitter:card is set to summary_large_image
Image renders correctly when you open the URL directly
You have tested with at least one social platform debugger

Wrapping Up

Adding proper OG images to a Next.js app is one of those 5-minute tasks that pays dividends every time someone shares your content. Whether you go with static metadata, dynamic generateMetadata, self-hosted @vercel/og, or an external service, the important thing is that you do it.

Your links deserve better than plain text.

Have questions about OG images in Next.js? Drop a comment below -- I read every one.

GEO vs SEO: Why Optimizing for AI Search Is the Next Frontier

Corbanware — Mon, 20 Apr 2026 01:00:50 +0000

Why Your Brand Is Invisible to ChatGPT (And How to Fix It)

Corbanware — Mon, 13 Apr 2026 01:00:49 +0000

I Built an AI Search Visibility Auditor - Here Is What I Learned

Corbanware — Mon, 06 Apr 2026 01:00:26 +0000

GEO vs SEO: Why Optimizing for AI Search Is the Next Frontier

Corbanware — Mon, 30 Mar 2026 01:00:36 +0000

Why Your Brand Is Invisible to ChatGPT (And How to Fix It)

Corbanware — Mon, 23 Mar 2026 01:00:31 +0000

I Built an AI Search Visibility Auditor - Here Is What I Learned

Corbanware — Mon, 16 Mar 2026 01:01:11 +0000

Building a Multi-LLM Fallback System with Vercel AI SDK

Corbanware — Mon, 09 Mar 2026 01:01:20 +0000

A practical guide to implementing LLM provider fallback chains for production applications. Covers the architecture of Geonapse's 3-tier fallback system (Gemini Flash-Lite ? Groq ? DeepSeek), error handling patterns, cost optimization strategies, response quality validation, and monitoring. Includes code examples using Vercel AI SDK's unified interface and lessons learned from running multi-provider LLM systems in production.

GEO vs SEO: Why Your Website Is Invisible to ChatGPT (And How to Fix It)

Corbanware — Mon, 02 Mar 2026 01:01:17 +0000

Generative Engine Optimization (GEO) is emerging as the next evolution of SEO. This article explores why traditional SEO techniques only partially work for AI search engines, what factors influence LLM brand recommendations, and a practical framework for auditing your AI search visibility. Covers knowledge graph presence, structured data importance, citation cascades, content structure optimization, and the growing importance of platform presence across Wikipedia, Crunchbase, G2, and other knowledge sources.

I Built an AI Search Visibility Auditor Here's the Architecture

Corbanware — Mon, 23 Feb 2026 01:01:07 +0000

A technical deep-dive into building Geonapse, an AI search visibility auditor. Covers the 3-tier LLM fallback architecture (Gemini Flash-Lite ? Groq ? DeepSeek), the 40+ check audit engine, ranking detection via AI search APIs, and platform presence scanning across 8 knowledge platforms. Built with Next.js 16, Vercel AI SDK, Neon PostgreSQL, and Drizzle ORM. Includes lessons learned about LLM reliability, cost optimization, and building evaluation frameworks for AI-generated content.