RenderCard - From My Blog Need to a Public OG API

How RenderCard started as a personal OG image solution and became a free URL-based API for social preview cards.

RenderCard started with a practical problem:

I needed clean OG images for my own blog posts, fast.

I didn't want to design every preview card manually, and I didn't want to depend on heavy tooling just to generate one image per post.

So I built a small internal generator for myself.

Then I realized this wasn't just my problem.

The original need

I wanted a simple way to generate:

• Open Graph images for blog links
• Featured images for articles
• Consistent visual style across posts

At first, this was just for my own writing workflow. I would pass title and metadata, generate a card, and move on.

That alone saved time.

From internal tool to public API

Once the core worked, I asked:

Why keep this locked inside one project?

So I turned it into a public, URL-based API where image generation happens through query parameters.

Base endpoint:

• https://rendercard.vercel.app/api/rendercard

Minimal usage:

• https://rendercard.vercel.app/api/rendercard?title=Hello+World

No dashboard. No login wall. Just a URL that returns a card image.

What RenderCard supports

RenderCard keeps the API intentionally small:

• title (required)
• description (optional)
• theme (optional)
• accent (optional hex color)
• date (optional: ISO date or unix ms)

Available themes:

• minimal
• centered
• split
• spotlight
• bordered
• gradient
• glass
• dark
• mono
• code

Unknown params are ignored safely, and unknown themes fall back to minimal.

Why I built it this way

I wanted RenderCard to be:

• Fast to use
• Easy to embed in any stack
• Good enough by default
• Flexible when needed

If you can construct a URL, you can generate a preview image.

That means it works well for:

• OG tags in blog pages
• Twitter/X cards
• Documentation articles
• Landing page announcements
• Internal tools that need visual previews

Tech direction

RenderCard is built with:

• Next.js
• Edge Runtime

Edge execution made sense here because OG image generation is request-driven and benefits from low-latency responses globally.

The focus was reliability and speed, not complexity.

What it is not

• Not a design suite
• Not a no-code editor
• Not trying to replace full creative tooling

It is a focused utility: turn text and metadata into clean social preview cards.

What comes next

Planned direction:

• Better typography controls
• More layout presets based on real usage
• Safer validation and clearer parameter errors
• Potential presets for blog engines

I'll keep it simple and useful first.

Closing

RenderCard began as a fix for my own content workflow.

Now it's a free API others can use too.

That is usually the best kind of side project: solve one real problem well, then open it up.

Links

• Live API Endpoint
• Support Page - If you have any suggestions please do submit here : /