DEV Community: Aldin Kozica

I built a WordPress plugin that turns any post title into a featured image (one click, no Canva)

Aldin Kozica — Tue, 26 May 2026 21:43:53 +0000

Every WordPress site I've worked on has the same friction: you write the post, you stare at the empty Featured Image slot, you go to Canva, design something, export it, upload it, set it. Then publish.

I got tired of that loop, so I built a plugin that does the whole "design + upload + set as featured" step with a single button.

This post is how it works under the hood — the small Gutenberg sidebar, the REST endpoint that sideloads to the Media Library, the brand-styled button. If you just want to install it, the link is at the bottom.

What it looks like

The plugin adds a panel to the block editor sidebar with Style, Category, and a Generate button. One click sends the post title to the ThumbAPI /v1/generate endpoint, downloads the returned image, and sets it as the post's featured image — all without leaving the editor.

The settings page is the same minimal pattern — paste an API key, pick a default style. Nothing else.

The architecture

The plugin is three pieces:

A REST endpoint registered under thumbapi/v1/generate-featured-image that takes a post_id and orchestrates the whole flow server-side.
A Gutenberg sidebar panel built with wp.element.createElement (no JSX, no build step) that calls that endpoint.
A classic editor fallback because plenty of WP installs still use it. Same flow, jQuery DOM injection below the Featured Image meta box.

The interesting part is the server side — translating an AI-generated image from a third-party API into a proper WordPress Media Library attachment.

Registering the REST endpoint

register_rest_route( 'thumbapi/v1', '/generate-featured-image', array(
    'methods'             => WP_REST_Server::CREATABLE,
    'callback'            => array( $this, 'handle_generate' ),
    'permission_callback' => array( $this, 'permission_check' ),
    'args'                => array(
        'post_id'     => array( 'required' => true, 'type' => 'integer', 'sanitize_callback' => 'absint' ),
        'image_style' => array( 'type' => 'string', 'sanitize_callback' => 'sanitize_text_field' ),
        'category'    => array( 'type' => 'string', 'sanitize_callback' => 'sanitize_text_field' ),
        // ...
    ),
) );

permission_callback is non-negotiable. The WP REST API will reject any unsanitized route at submission time to wordpress.org:

public function permission_check( WP_REST_Request $request ) {
    $post_id = (int) $request->get_param( 'post_id' );
    if ( $post_id <= 0 || ! current_user_can( 'edit_post', $post_id ) ) {
        return new WP_Error( 'thumbapi_forbidden', __( 'You cannot edit this post.', 'thumbapi' ), array( 'status' => 403 ) );
    }
    if ( ! current_user_can( 'upload_files' ) ) {
        return new WP_Error( 'thumbapi_no_upload', __( 'You cannot upload files.', 'thumbapi' ), array( 'status' => 403 ) );
    }
    return true;
}

Two capabilities, both needed: edit_post for the specific post ID, and upload_files because we're about to write to the Media Library.

Sideloading the generated image

ThumbAPI returns a data:image/webp;base64,... URI. The job is to decode it, write it to wp-content/uploads/, register it as a proper attachment so WordPress can generate thumbnail/medium/large sizes from it, and return the attachment ID:

public static function sideload_data_uri( $data_uri, $post_id, $filename ) {
    if ( ! preg_match( '#^data:image/([a-z0-9+.-]+);base64,(.+)$#i', $data_uri, $matches ) ) {
        return new WP_Error( 'thumbapi_invalid_data_uri', __( 'Invalid image.', 'thumbapi' ) );
    }

    $mime_subtype = strtolower( $matches[1] );
    $decoded      = base64_decode( $matches[2], true );
    if ( false === $decoded ) {
        return new WP_Error( 'thumbapi_decode_failed', __( 'Could not decode image.', 'thumbapi' ) );
    }

    require_once ABSPATH . 'wp-admin/includes/file.php';
    require_once ABSPATH . 'wp-admin/includes/image.php';
    require_once ABSPATH . 'wp-admin/includes/media.php';

    $uploads  = wp_upload_dir();
    $ext      = 'webp'; // simplified
    $unique   = wp_unique_filename( $uploads['path'], sanitize_file_name( $filename ) . '.' . $ext );
    $filepath = trailingslashit( $uploads['path'] ) . $unique;

    file_put_contents( $filepath, $decoded );

    $attachment_id = wp_insert_attachment( array(
        'guid'           => trailingslashit( $uploads['url'] ) . $unique,
        'post_mime_type' => 'image/' . $mime_subtype,
        'post_title'     => sanitize_file_name( $filename ),
        'post_status'    => 'inherit',
    ), $filepath, $post_id, true );

    $metadata = wp_generate_attachment_metadata( $attachment_id, $filepath );
    wp_update_attachment_metadata( $attachment_id, $metadata );

    return (int) $attachment_id;
}

That last wp_generate_attachment_metadata call is what makes the image a proper WordPress citizen — WP scans dimensions, generates intermediate sizes, populates srcset data. Skip it and your <img srcset> is empty.

After that, one line to wire it up:

set_post_thumbnail( $post_id, $attachment_id );

The Gutenberg sidebar (no JSX, no build step)

I deliberately wrote the editor JS without JSX. WordPress plugins that ship a Webpack bundle are an immediate review red flag — wordpress.org reviewers want code they can read in 30 seconds without running a build. wp.element.createElement is verbose but cheap to ship:

( function ( wp ) {
    var el = wp.element.createElement;
    var registerPlugin = wp.plugins.registerPlugin;
    var PluginDocumentSettingPanel = wp.editPost.PluginDocumentSettingPanel;
    var Button = wp.components.Button;
    var Dropdown = wp.components.Dropdown;
    var apiFetch = wp.apiFetch;
    var __ = wp.i18n.__;

    function ThumbAPIPanel() {
        var style = wp.element.useState( 'faceless' );
        var loading = wp.element.useState( false );
        var post = wp.data.useSelect( function ( select ) {
            var core = select( 'core/editor' );
            return { id: core.getCurrentPostId(), title: core.getEditedPostAttribute( 'title' ) };
        }, [] );
        var editorDispatch = wp.data.useDispatch( 'core/editor' );

        function handleGenerate() {
            loading[ 1 ]( true );
            apiFetch( {
                path:   '/thumbapi/v1/generate-featured-image',
                method: 'POST',
                data:   { post_id: post.id, title: post.title, image_style: style[ 0 ] },
            } ).then( function ( res ) {
                if ( res && res.attachment_id ) {
                    editorDispatch.editPost( { featured_media: res.attachment_id } );
                }
                loading[ 1 ]( false );
            } );
        }

        return el( PluginDocumentSettingPanel, { name: 'thumbapi-panel', title: 'ThumbAPI' },
            // …style + category dropdowns here
            el( Button, { variant: 'primary', disabled: loading[ 0 ], onClick: handleGenerate },
                loading[ 0 ] ? 'Generating…' : 'Generate'
            )
        );
    }

    registerPlugin( 'thumbapi-featured-image', { render: ThumbAPIPanel } );
} )( window.wp );

apiFetch automatically attaches the X-WP-Nonce header, so REST auth Just Works as long as the user is logged in. editorDispatch.editPost({ featured_media: attachmentId }) is the canonical way to update the featured image from JS — the editor reacts immediately, no full reload.

Media Library picker for the "with photo" style

ThumbAPI supports a personImage parameter (base64) for compositing a face or logo into the thumbnail. For WordPress users, the natural source for that is the Media Library — they already have their face/logo there. So instead of forcing them back to a dashboard upload, the plugin uses wp.blockEditor.MediaUpload:

el( wp.blockEditor.MediaUpload, {
    allowedTypes: [ 'image' ],
    onSelect:     function ( m ) {
        setMedia( {
            id:               m.id,
            url:              m.url,
            filename:         m.filename,
            filesizeInBytes:  m.filesizeInBytes,
        } );
    },
    render: function ( ctx ) {
        return el( Button, { variant: 'secondary', onClick: ctx.open }, 'Choose image' );
    },
} )

When the user generates, the server reads that attachment back, base64-encodes it, and ships it inline:

public static function encode_attachment_base64( $attachment_id ) {
    $file = get_attached_file( $attachment_id );
    if ( ! $file || ! file_exists( $file ) ) {
        return new WP_Error( 'thumbapi_attachment_missing_file', __( 'File missing.', 'thumbapi' ) );
    }
    if ( filesize( $file ) > 2 * 1024 * 1024 ) {
        return new WP_Error( 'thumbapi_attachment_too_large', __( 'Over 2 MB.', 'thumbapi' ) );
    }
    $mime  = get_post_mime_type( $attachment_id );
    $bytes = file_get_contents( $file );
    return 'data:' . $mime . ';base64,' . base64_encode( $bytes );
}

Two megabyte cap is enforced both client- and server-side. Client-side gives the user a clear "Over 2 MB" notice before they click Generate; server-side stops anyone who skips the UI.

Things I had to fight with

A few WordPress.org review gotchas I hit along the way:

Plugin URI and Author URI cannot be the same. Set them to different values or omit one. I put Plugin URI: https://thumbapi.dev and Author URI: https://www.linkedin.com/in/... to separate them.
Text Domain must match the plugin slug exactly. If your plugin is thumbapi-auto-featured-images, your text domain has to be the same string. Mismatch is a warning at submit time.
Domain Path: /languages requires the folder to exist — even if you don't ship translations yet. Easier to omit the header until you do.
No bundled libraries. jQuery, React, wp.element, etc. — all from WordPress core. No Webpack output that re-bundles them.
REST endpoints need real permission_callback that calls current_user_can(). Returning true from permission_callback is an instant rejection.

Install it

The plugin is currently in review on the WordPress.org Plugin Directory (slug: thumbapi). Until it lists, you can install it manually:

Download: https://thumbapi.dev/downloads/thumbapi-wordpress.zip
Full integration page: https://thumbapi.dev/integrations/wordpress

You need a free ThumbAPI key (5 generations/month on the free tier). After install: Settings → ThumbAPI → paste key → open any post → click Generate.

Source

The official plugin ships through WordPress.org and the link above. The single-file auto-on-publish reference example (different flow — fires on transition_post_status instead of a button) lives in the examples repo: github.com/dinalllll/thumbapi-examples/tree/main/wordpress.

If you build something on top of this — or hit a bug — I'd love to know.

Originally published on thumbapi.dev/integrations/wordpress.

How to Auto-Generate YouTube Thumbnails with Make.com (Step-by-Step)

Aldin Kozica — Sun, 24 May 2026 20:04:06 +0000

Thumbnail creation is the last manual step in most content pipelines. You write the video title, edit the footage, write the description — and then you open Canva or Photoshop and spend 20 minutes designing an image you could have generated in under 30 seconds.

This guide closes that gap with Make.com (the visual no-code automation platform, formerly Integromat). By the end you will have a scenario that takes any title and returns a production-ready thumbnail you can save to Google Drive, attach to a Slack message, or set as a WordPress featured image. The whole setup is under 10 minutes if you use the public scenario template.

If you prefer code-first workflows in n8n, see the n8n version of this guide. This post is the Make.com-specific deep dive.

What You Are Building

The core scenario is:

Receive a trigger (RSS, YouTube watch videos, Google Sheets row, Webhook — anything that produces a title)
Send the title to ThumbAPI via an HTTP module
Decode the base64 image response into binary data
Upload the thumbnail to Google Drive, post to Slack, or push to your CMS

Make.com handles the entire flow in a visual canvas — no code required beyond a few small formulas in the variable transform step.

Prerequisites

Before starting, you need:

A Make.com account (free tier covers 1,000 ops/month — more than enough for this scenario)
A ThumbAPI account with an API key (free tier: 5 generations/month, no credit card)
A Google Drive account if you want to use the Drive destination shown in the examples

Plug-and-Play: Clone the Public Scenario

The fastest path is to clone the ready-made scenario in one click:

Clone the Make.com scenario template →

The clone drops three modules into your Make account:

Set variable — a placeholder trigger holding a sample title.
HTTP — Make a request — POSTs to the ThumbAPI generate endpoint.
Set multiple variables — strips the base64 data URI prefix and computes a fileName + mimeType you can feed into any file module.

The cloned scenario ships with the public test key thumbapi_test. That key returns a static placeholder image so you can confirm the wiring works without spending credits. To generate real thumbnails, swap it for your own API key from app.thumbapi.dev.

If you want to understand what each module does (or build it from scratch in your own scenario), the next sections walk through every step.

Step 1: Get Your ThumbAPI Key

Sign up at app.thumbapi.dev and copy your API key from the dashboard. The free plan includes 5 generations per month — enough to test and build the scenario.

You will paste this key into the HTTP module's headers in the next step.

Step 2: Create a New Scenario and Add a Trigger

In Make.com, click Create a new scenario (top right of the dashboard). The trigger module determines what kicks off thumbnail generation:

YouTube — Watch Videos — fires when you publish a new video.
RSS — Watch RSS Feed Items — works for any blog or YouTube channel that exposes a public feed.
Google Sheets — Watch Rows — for content calendars where each row is one title.
Webhook — Custom Webhook — universal, your own app POSTs the title.
Tools — Set variable — a manual placeholder useful while testing.

Connect your account, then Run this module once to load sample data. Make uses the sample to populate field mappings in downstream modules.

Step 3: Add the HTTP Module

Click + after your trigger and search for HTTP. Select Make a request. This is Make's built-in module for calling external APIs.

Configure it as follows:

URL:                 https://api.thumbapi.dev/v1/generate
Method:              POST

Headers (Add item):
  Name:  x-api-key
  Value: YOUR_THUMBAPI_KEY
  Name:  Content-Type
  Value: application/json

Body type:           Raw
Content type:        JSON (application/json)
Request content:     (see below)
Parse response:      Yes

In the Request content field, paste:

{
  "title": "{{1.title}}",
  "format": "youtube",
  "imageStyle": "faceless",
  "outputFormat": "webp"
}

The {{1.title}} expression pulls the title from the trigger module (module 1 in your scenario). When you click into the field, Make's right-side panel shows available variables — click the title variable to insert the reference automatically.

Format and Style Options

Parameter	Options
`format`	`youtube`, `instagram`, `x`, `blogpost`, `linkedin`
`imageStyle`	`faceless`, `with-image`, `with-logo`
`outputFormat`	`webp` (default), `png`

For YouTube, faceless generates text-and-graphic designs optimized for click-through. Switch to with-image if you have uploaded a profile photo in the ThumbAPI dashboard and want your face included.

Step 4: Test the HTTP Module

Right-click the HTTP module and select Run this module only. Make sends the request to ThumbAPI and displays the response:

{
  "image": "data:image/webp;base64,UklGR...",
  "format": "youtube",
  "outputFormat": "webp",
  "dimensions": {
    "width": 1280,
    "height": 720
  }
}

The image field is the full base64-encoded WebP. With Parse response: Yes, Make automatically extracts image, format, outputFormat, and dimensions as mappable variables for downstream modules.

If the module fails, check:

The header name is exactly x-api-key (not Authorization)
The API key is correct and active in your ThumbAPI dashboard
The title field in your request body is not empty
Body content is valid JSON (Make is strict about quotes and commas)

Step 5: Decode the Base64 Image

Make's toBinary() function converts a base64 string into binary data that file modules can consume directly. Add a Tools → Set multiple variables module after the HTTP module with three variables:

Variable name:  imageData
Variable value: {{toBinary(replace(2.data.image; "data:image/webp;base64,"; ""))}}

Variable name:  fileName
Variable value: thumbnail-{{formatDate(now; "X")}}.{{ifempty(2.data.outputFormat; "webp")}}

Variable name:  mimeType
Variable value: image/{{ifempty(2.data.outputFormat; "webp")}}

What this does:

2.data.image references the image field from the HTTP response (module 2).
replace(...; "data:image/webp;base64,"; "") strips the data URI prefix.
toBinary(...) converts the cleaned base64 string into a binary buffer.
formatDate(now; "X") is a Unix timestamp — prevents filename collisions.
ifempty(...) falls back to webp if outputFormat is missing.

Step 6: Upload the Thumbnail to Google Drive

Add a Google Drive — Upload a file module. Connect your Google account when prompted, then map the variables from the previous step:

Folder:          (pick your destination folder)
File name:       {{3.fileName}}
File data:       {{3.imageData}}

If you prefer Dropbox, S3, or any other file destination, the pattern is identical — every file module accepts the binary buffer produced by toBinary().

Step 7: Add a Slack Notification (Optional)

For team workflows, append a Slack — Send a Message module after the upload:

Channel:  #thumbnails
Text:     Thumbnail ready for: {{1.title}}
          Drive link: {{4.webViewLink}}

Your scenario now detects, generates, uploads, and notifies — fully hands-off.

Handling Multiple Platforms at Once

If you distribute the same content across YouTube, Instagram, and your blog, Make's Router module lets you fan out from a single trigger into parallel paths:

[Trigger]
   ↓
[Router]
   ├── Route 1: HTTP → format: youtube     → Google Drive: YouTube/
   ├── Route 2: HTTP → format: instagram   → Instagram: Create Post
   └── Route 3: HTTP → format: blogpost    → WordPress: Update Featured Image

Each route runs independently. If one fails, the others still complete. Add filters to routes to conditionally generate thumbnails based on category, post type, or any field from the trigger.

Error Handling for Production Scenarios

Make.com makes error handling straightforward:

Enable error handlers on the HTTP module. Right-click the module and add an error route — typically a Slack alert plus a retry. Make retries the request automatically if you select the "Retry" handler type.
Set "Allow storing of incomplete executions" in the scenario's advanced settings so failed runs don't disappear silently.
Add a Sleep module between iterations in batch scenarios (1–2 seconds) to avoid hitting the ThumbAPI rate limit when processing many titles in a row.

Batch Processing From Google Sheets

For weekly content calendars, this pattern processes all titles in one Monday morning run:

[Schedule Trigger]    — every Monday at 9 AM
  ↓
[Google Sheets]       — Search Rows: this week
  ↓
[HTTP]                — POST to ThumbAPI with row title
  ↓
[Set multi variables] — decode base64 → binary
  ↓
[Google Drive]        — Upload thumbnail to weekly folder
  ↓
[Google Sheets]       — Update Row: mark "Thumbnail: Generated"

Each row can specify its own format and imageStyle columns, so YouTube, blog, and Instagram thumbnails all come from the same weekly run.

Why Make.com for Thumbnail Automation

Make's strengths show up in three places:

Visual flow. You see the entire pipeline as a connected diagram — easy to explain to non-developers on your team and easy to debug because each module shows its actual data on every run.

Router and Iterator modules. Fan out into parallel paths or batch-process hundreds of rows from a spreadsheet without writing a loop.

Operations-based pricing. Each module run is one operation. The free tier (1,000 ops/month) is enough for ~100 thumbnail generations including all the surrounding modules. Above that, plans start at $9/month for 10k ops.

If you prefer the code-first model with a Code node for custom JavaScript transforms, the n8n version of this guide covers the same flow with n8n's terminology.

Getting Started

The fastest path from zero to working Make.com thumbnail automation:

Sign up for Make.com — free tier, no credit card.
Sign up for ThumbAPI — free tier, 5 generations/month.
Clone the public scenario template.
Swap thumbapi_test for your real ThumbAPI key in the HTTP module headers.
Replace the Set variable placeholder with your real trigger (YouTube, RSS, Sheets, Webhook).
Add your destination module (Google Drive, Slack, WordPress, etc.) and map imageData, fileName, mimeType.

Total time: 10–15 minutes. Thumbnail generation itself runs in under 25 seconds per request.

For the canonical Make.com setup with all configuration details, see the ThumbAPI + Make.com integration guide.

Originally published at thumbapi.dev/integrations/make.

How to Auto-Generate YouTube Thumbnails with n8n (Step-by-Step)

Aldin Kozica — Thu, 21 May 2026 06:54:54 +0000

This guide shows you how to close that gap entirely. By the end, you will have an n8n workflow that detects new YouTube uploads, sends the video title to ThumbAPI, and saves a production-ready thumbnail to Google Drive automatically. No design software, no manual steps.

The guide is written for developers and technically comfortable creators. If you want a higher-level overview of content automation, the developer's guide to automating content creation covers the broader picture. This post is the n8n-specific deep dive.

What You Are Building

The core workflow is:

Detect a new YouTube video (via RSS or webhook)
Extract the video title
Call ThumbAPI with the title and target format
Receive a base64-encoded WebP thumbnail
Upload the thumbnail to Google Drive (or your CMS)
Optionally notify your team via Slack

This workflow runs entirely inside n8n. You can self-host it on your own server or use n8n Cloud — the node configuration is identical either way.

Prerequisites

Before starting, you need:

An n8n instance (self-hosted or n8n Cloud)
A ThumbAPI account with an API key — the free tier is enough to test
A YouTube channel ID (find it in YouTube Studio under Settings → Channel → Advanced settings)
A Google Drive account if you want to use the Drive destination in the examples

Step 1: Store Your ThumbAPI Key as a Credential

Never put API keys directly into HTTP Request nodes. n8n's credential manager encrypts them and keeps them out of your workflow JSON exports.

Go to Settings → Credentials → Add Credential and choose Header Auth:

Name:         ThumbAPI
Header Name:  x-api-key
Header Value: YOUR_THUMBAPI_KEY

Save the credential. You will select it in every HTTP Request node that talks to ThumbAPI.

Why x-api-key? ThumbAPI authenticates via the x-api-key header, not a Bearer token. Make sure the header name matches exactly.

Step 2: Create the Workflow and Add a Trigger

Open n8n and click New Workflow. The trigger node determines what kicks off thumbnail generation. The two most useful options for YouTube content are:

Option A: RSS Feed Trigger (Recommended for YouTube)

YouTube publishes an RSS feed for every channel. The RSS Feed Read node polls it on a schedule and fires when a new video appears.

Node:          RSS Feed Read
Feed URL:      https://www.youtube.com/feeds/videos.xml?channel_id=YOUR_CHANNEL_ID
Poll Every:    15 minutes

Replace YOUR_CHANNEL_ID with your actual channel ID. n8n will pass the video title as $json.title to downstream nodes.

Option B: Webhook Trigger (For CMS or Custom Pipelines)

If you publish video metadata to a CMS before uploading to YouTube, use a Webhook trigger instead. Your CMS fires a POST request to the n8n webhook URL when content is ready.

Node:     Webhook
Method:   POST
Path:     /new-video

The webhook payload should include at minimum a title field. Everything else is optional.

Step 3: Add the ThumbAPI HTTP Request Node

Click + after your trigger and add an HTTP Request node. This is the node that calls ThumbAPI to generate the thumbnail.

Configure it as follows:

Method:              POST
URL:                 https://api.thumbapi.dev/v1/generate
Authentication:      Generic Credential Type → Header Auth
Credential:          ThumbAPI (the one you created in Step 1)
Send Body:           true
Body Content Type:   JSON

Set the JSON body:

{
  "title": "{{ $json.title }}",
  "format": "youtube",
  "imageStyle": "faceless",
  "outputFormat": "webp"
}

The {{ $json.title }} expression pulls the video title from the trigger output. If your trigger uses a different field name, adjust the expression accordingly.

Format and Style Options

Parameter	Options
`format`	`youtube`, `instagram`, `x`, `blogpost`, `linkedin`
`imageStyle`	`faceless`, `with-image`, `with-logo`
`outputFormat`	`webp` (default), `png`

For YouTube, faceless generates text-and-graphic designs optimized for click-through. If you have uploaded a profile photo to the ThumbAPI dashboard, switch to with-image to include your face in every generated thumbnail.

Step 4: Test the HTTP Request Node

Before building out the rest of the workflow, test this node in isolation. Click Execute Node. If the request succeeds, you will see the response in n8n's output panel:

{
  "image": "data:image/webp;base64,UklGR...",
  "format": "youtube",
  "outputFormat": "webp",
  "dimensions": {
    "width": 1280,
    "height": 720
  }
}

The image field is the full base64-encoded WebP. A typical YouTube thumbnail is 50–150 KB encoded, which n8n handles without issues.

If the node fails, check:

The credential header name is exactly x-api-key (not Authorization)
The API key is correct and active in your ThumbAPI dashboard
The title field in your request body is not empty

Step 5: Decode the Image and Upload to Google Drive

The base64 string needs to be converted into n8n binary data before you can upload it. Add a Code node between the HTTP Request node and your destination:

const base64String = $input.item.json.image;

const base64Data = base64String.includes(',')
  ? base64String.split(',')[1]
  : base64String;

const outputFormat = $input.item.json.outputFormat || 'webp';

return {
  json: {
    title: $input.item.json.title,
    format: $input.item.json.format,
    outputFormat,
  },
  binary: {
    data: {
      data: base64Data,
      fileName: `thumbnail-${Date.now()}.${outputFormat}`,
      mimeType: `image/${outputFormat}`,
    },
  },
};

This blogpost image is generated by ThumbAPI

Stop Hardcoding Templates: How I Feed a Live 3x2 Inspiration Grid into Gemini Flash

Aldin Kozica — Fri, 15 May 2026 19:48:28 +0000

Every developer building a tech blog, open-source documentation site, or SaaS product hits the same annoying roadblock: Open Graph (OG) images. When you share your project on Twitter/X, LinkedIn, or dev.to, a generic background with text gets ignored. But spending 15 minutes in Canva for every single release or article is a massive productivity killer.

I wanted to completely automate this, but static, hardcoded templates are boring. Instead, I built a backend pipeline that looks at what is currently trending live, builds a single 3x2 visual inspiration grid from those trends, and feeds that image into Gemini Flash to generate a brand new, context-aware OG asset.

The best part? It adapts to shifting design trends completely on autopilot, with ZERO room for AI hallucinations.

The Conceptual Architecture: Zero Room for Hallucinations 🛡️

The biggest issue with using GenAI for visual production is predictability. If you give an LLM too much freedom, it will hallucinate weird layouts, bad fonts, or completely off-brand designs.

To fix this, my pipeline doesn't let the AI "think" from scratch. It builds a strict visual and contextual cage around it. Here is how the execution flow looks:

Trigger: New Post or Git Push detected.
Step 1: Scrape Live Trend Images using Node.js on a Hetzner VPS.
Step 2: Compile those images into a single 3x2 Grid Image (The Visual Guardrail).
Step 3: Send the compiled Grid + Strict Title to the Gemini Flash API.
Result: A deterministic, on-trend 1200x630 OG Image is generated.

1. The Live Trend Fetch

When a new post or release is detected, the backend quickly scrapes the top-performing visual assets under that specific tech niche.

2. The Grid Compilation

The system takes those top 6 live image results and programmatically compiles them into a single 3x2 image grid buffer. This grid acts as our visual guardrail.

3. The Multimodal Constraint

We send this single grid image directly to Gemini Flash alongside the exact title of the new post.

Because Gemini Flash receives a concrete visual sample (the grid) and a literal text string (the title), there is absolutely no room for it to invent custom nonsense or hallucinate. It is forced to morph the existing design patterns it sees in the grid with the exact input parameters provided to the underlying generation engine—which I abstracted into a dedicated infrastructure tool called ThumbAPI.

The Prompt Logic: Turning Inspiration into Assets 🧠

Since the model is multimodal, you don't need to write complex image-processing algorithms. You just need to guide the AI's "designer eye" to extract patterns from the grid rather than creating something out of thin air:

Visual Pattern Extraction: The model scans the 3x2 grid to isolate the dominant layout structures (e.g., whether the community is currently leaning toward minimalist code blocks, dark mode neon gradients, or abstract geometric shapes).
Contrast Alignment: It determines how to place your specific text inside that exact structure so it pops inside the current active feed.
Title Integration: It maps the new post title into the calculated visual framework and outputs the final deployment-ready 1200x630 WebP image.

Why This Pipeline Wins

Autopilot Relevancy: The images aren't random or stuck in the past. If the dev community suddenly shifts its aesthetic preferences, the scraper catches it, the grid changes, and the AI automatically matches the current vibe.
Infrastructure Efficiency: By hosting the scraper and grid compiler on a low-cost Hetzner VPS and pairing it with Gemini Flash's speed, running this production pipeline costs next to nothing.
No Canva Required: The pipeline finishes in seconds, updating the CMS or repository automatically right after a git push.

Let's Discuss: How do you handle your project assets? 🚀

Moving the inspiration and rendering pipeline completely to a programmatic, image-to-image AI workflow has completely changed how I ship content. It bridges the gap between pure code and marketing design without relying on unpredictable prompt engineering.

I’d love to get your thoughts in the comments:

How are you currently generating OG images or headers for your side projects? Do you stick to static code-generated templates, or do you still build them manually?
Have you experimented with using multimodal image inputs as strict guardrails to stop AI hallucinations?

Drop a comment below if you want to know more about the n8n integration, or feel free to check out ThumbAPI if you want to test the programmatic asset generation logic yourself!

P.S. All visual materials and image grids shown in this post were generated programmatically using ThumbAPI.

I was spending 2 hours a week making thumbnails. Here's the n8n workflow that fixed it.

Aldin Kozica — Wed, 13 May 2026 17:22:30 +0000

I run a small content automation pipeline. RSS feeds, AI summaries, auto-publishing — the usual stuff.

Everything was automated except thumbnails.

Every time a new blog post went live, I'd open Canva, drag some text around, pick a background, export it, upload it. 10–15 minutes per post. Multiply that by 8–10 posts a week and you get the picture.

It wasn't hard work. It was boring work. The worst kind.

So I spent a weekend building a workflow that does it for me. Here's exactly how it works.

The setup

My publishing pipeline already ran on n8n. When a new post goes live on my blog, a webhook fires and kicks off a chain: notify newsletter, post to Twitter, update Notion.

Adding thumbnail generation was just one more node.

The idea: when a post publishes → generate a thumbnail → upload it back to the CMS.

The HTTP node that does the work

I used ThumbAPI — a REST API that takes a title and returns a ready-made thumbnail image. One POST request, one image back as base64.

Here's the exact node config in n8n:

Method: POST

URL: https://api.thumbapi.dev/v1/generate

Authentication: Header — Authorization: Bearer YOUR_API_KEY

Body (JSON):

{
  "title": "{{ $json.post_title }}",
  "format": "blogpost",
  "imageStyle": "faceless"
}

That's it. The $json.post_title pulls the title from the previous node in the workflow — whatever just triggered the webhook.

What comes back

The response looks like this:

{
  "image": "data:image/webp;base64,/9j/4AAQSkZJRgAB...",
  "format": "blogpost",
  "dimensions": { "width": 1200, "height": 630 }
}

A base64 WebP image, correct dimensions for blog OG images (1200×630), ready to use.

Connecting it to my CMS

Next node: an HTTP request to my CMS API to upload the image and attach it to the post. The exact steps depend on your CMS — I'm on a custom setup — but if you're on WordPress, Ghost, or anything with a REST API, it's the same pattern: decode base64, POST to your media endpoint, get back an image ID, attach to the post.

In n8n this is just two more nodes:

Code node — strip the data:image/webp;base64, prefix and convert to binary
HTTP node — POST to your CMS media endpoint

The full workflow in plain English

Blog post published (Webhook)
  → Generate thumbnail (HTTP POST to ThumbAPI)
  → Convert base64 to binary (Code node)
  → Upload to CMS (HTTP POST to media endpoint)
  → Attach thumbnail to post (HTTP PATCH)

Five nodes. Runs in about 25 seconds. Zero Canva.

What I'd do differently

The faceless style is great for blogs but if you're doing YouTube thumbnails and want your face on them, ThumbAPI supports uploading a reference photo and reusing it across generations. I haven't set that up yet but it's next.

Also: error handling. Right now if the API call fails, the workflow just stops. I need to add a fallback node that pings me on Slack so I can manually handle it. Classic "it works, ship it" problem.

Is it worth it?

I've now run this for about 6 weeks. Zero manual thumbnails since. The images aren't as polished as what I'd make in Canva on a good day, but they're consistent, on-brand, and they exist — which is more than I can say for the weeks I'd skip thumbnails because I didn't have time.

If you have any automation pipeline that produces content regularly, this is a low-effort, high-payoff addition.

Happy to share the full n8n workflow JSON if anyone wants it — drop a comment.
PS:This cover blogpost image is generated by ThumbAPI.

Thumbapi.dev solution i made to automate content creation workflows + API

Aldin Kozica — Tue, 12 May 2026 16:56:36 +0000

I've been having a lot of problems wiht the social media and my marketing. Creating a social post,video or blogpost took me so much time and energy.
I wanted to automate best i could of this proces so i started https://thumbapi.dev that actualy creates me visuals instantly for any kind of social posts.
There is couple of features:

Faceless visuals
With personal photo
With branded logo
With custom dataset So i could basicaly automate all platform in one place without wasting alot of time with finding inspiration for covers/thumbnails.

1) This image is example of faceless blogpost visual + branded logo + title: "Built a tool that social visuals from a title automatically"

2) Another example is youtube thumbnail + personal image + title : "Built a tool that social visuals from a title automatically"

3) Last example is faceless blogpost + no brand / no photo + title "Built a tool that social visuals from a title automatically"

There is also output image format WEBP or PNG.
WEBP for blogpost and best load optimization and PNG for youtube better quality thumbnails.

Dealing with the first user feedback: The good, the bad, and the Brave Browser

Aldin Kozica — Wed, 22 Apr 2026 07:44:42 +0000

After 3 months of diving into SaaS discovery, marketing, and content creation—things that often make me feel uncomfortable as a developer—I finally got a sign that gave me a huge push.

There’s nothing quite like getting that first email from a stranger using your tool. I recently launched YouThumb Tester, and the first piece of feedback just landed in my inbox.

The Reality Check

Building in a silo is one thing, but real-world usage always reveals the cracks:

The Bug: It seems like there's a caching or injection issue on Brave Browser. The thumbnail doesn't always show up instantly without multiple reloads. Brave's aggressive shields might be playing a role here.
The UX Flaw: I completely missed a "clear/disable" button. Once the user is done testing, the preview persists in their feed. That's a friction point I need to kill immediately.

The Extension Struggle: Waiting for Approval ⏳

Here is the kicker for anyone who isn't a browser extension dev: The fix isn't instant.

Unlike a standard web app where I can just push a hotfix to the server and it's live for everyone in seconds, the Chrome Web Store (and other stores) has a manual review process.

Even if I fix this bug in 10 minutes, I have to:

Bundle the new version.
Submit it for review.
Wait anywhere from 24 hours to several days for it to be approved.

It’s a strange feeling knowing there is a bug out there and having the solution ready, but being forced to wait behind a "Pending Review" status.

The Win 🚀

Despite the technical hiccups, the user mentioned they "really love the extension" and specifically the advice it provides during the test. This is the ultimate fuel for any solo dev. It validates that the core value proposition is there, even if the implementation needs polish.

Next Steps

Brave Debugging: Investigating DOM injection issues specifically for Chromium-based browsers.
The "Reset" Button: Adding a clear "Reset to Original" button in the popup.
Better State Management: Improving logic so the preview doesn't "ghost" after the user's session.

Technical note: I tried to move as much logic as possible to my Node.js backend to keep the extension "thin," but since the issue is with DOM injection and Brave's shields, the fix still has to go through the content-script. I'm currently looking into implementing a Remote Config strategy to update selectors and UI flags via API, so I don't have to wait for a store review every time a CSS class changes.

Check out the project here: YouThumb.online

From 0 to 50 Users in 2 Months: Building a Chrome Extension with React, Node.js, and Gemini Nano

Aldin Kozica — Wed, 15 Apr 2026 18:24:40 +0000

Building a browser extension sounds simple until you actually try to scale it. Two months ago, I launched YouThumb a tool that help creators with the thumbnails to optimize CTR with AI, and while 50 users might seem small to some, the technical and marketing journey to get there was a massive learning curve.

Here is the exact stack I used and what I’ve learned about launching a dev-tool.

The Architecture (The "Banana" Stack 🍌)
I wanted a setup that was both scalable and cost-effective. Here’s how it looks:

Frontend (Extension): Built with React. It handles the UI for thumbnail comparisons and the overlay logic on the YouTube DOM.

Backend: A Node.js API hosted on a Hetzner VPS. I chose Hetzner for the high performance-to-cost ratio, which is crucial when you're a solo founder keeping margins high.

Database & Auth: Firebase. It’s still the king for quick implementation of Google Auth and real-time data syncing.

The AI Brain: I’m using Gemini Nano for on-device analysis. It allows for fast, multimodal processing without the heavy latency (or cost) of constantly hitting a cloud API.

Landing Page: Built with Next.js for that sweet SEO and fast load times.

Check out the landing page here: [https://youthumb.online/]

The 50-User Milestone: What Worked?
Getting those first 50 users wasn't about "build it and they will come." It was about being where the creators are.

Building in Public: Documenting the OAUTH struggles and the "Featured" badge win on social media.

Dogfooding: Using the tool for my own YouTube channel and showing the results.

The "Featured" Badge: This was a game-changer for credibility in the Chrome Web Store.

The Biggest Challenge: The "Manifest.json" & OAUTH Trap
If you’ve worked with Manifest V3, you know the pain. My biggest nightmare was aligning Firebase Auth with Chrome’s identity API while moving the backend to a dedicated VPS. It’s a delicate dance of redirect URIs and background service worker lifecycles.
Also in addition a feature badge on chrome store to build trust and authority.

I need your advice: How to scale from 50 to 500?
Now that the technical foundation is solid and the first 50 users are providing feedback, I’m looking at the next phase.

My question to the Dev.to community:
How do you approach marketing for a browser extension? Should I focus on SEO for the landing page YouThumb, or double down on niche communities like Reddit, Discord or Youtube? If you’ve launched an extension, what was your "inflection point" for growth?

Let’s discuss in the comments!

webdev #showdev #javascript #ai #node #buildinpublic #chromextension #discuss