DEV Community: Roman Popovych

Breadcrumb Schema Markup: The Complete Guide to Structured Data for Site Navigation

Roman Popovych — Tue, 19 May 2026 06:16:27 +0000

Below the title in a search result, Google shows either a raw URL or a clean path like example.com › Tools › Image Converter. The path version comes from breadcrumb schema. It's one of the smallest implementation efforts in structured data and one of the most consistently effective — it works for almost any site, not just specific content types.

This is also where a lot of developers get tripped up on small things. The position field needs to be sequential with no gaps. Every URL in item needs to resolve. Minimum two items — a single-item breadcrumb is invalid per spec. These aren't complicated rules, but they're the ones that silently break implementations.

What's covered: the correct structure for shallow and deep hierarchies, how to generate breadcrumbs dynamically from URL paths, combining breadcrumb schema with other schema types on the same page, and the six mistakes that show up most often in validation reports.

What Is Breadcrumb Schema?

BreadcrumbList is a schema.org type that describes a page's position in a site hierarchy — the navigation path from the homepage to the current page. You implement it as JSON-LD and Google uses it to replace the URL display in search results with a human-readable path.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Tools",
      "item": "https://example.com/tools"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Image Converter",
      "item": "https://example.com/tools/image-converter"
    }
  ]
}

This produces example.com › Tools › Image Converter in search results instead of the raw URL.

What Breadcrumb Schema Looks Like in Search Results

The breadcrumb trail replaces the green URL text that appears below the page title in standard search results. Before breadcrumb schema (or when it's not detected), Google shows the URL — often long, often ugly, often including query parameters. With it, you get a clean hierarchical path.

Before: https://example.com/en/tools/image/converter?format=webp&quality=85

After: example.com › Tools › Image Converter

The improvement has two practical effects:

Readability. Users understand immediately where this page lives in your site's structure. A page that says Tools › Image Converter communicates category context before the user clicks.

CTR. Cleaner, shorter path displays often improve click-through rates, particularly on mobile where long URLs truncate awkwardly. The breadcrumb display is also slightly more compact, giving more visible space to the title and description.

When Google Shows Breadcrumbs in Search Results

Google uses two sources to generate breadcrumb trails in search results:

Breadcrumb schema — explicit structured data you provide
URL structure — Google's own parsing of your URL path as a fallback

If you implement breadcrumb schema correctly, Google uses your data and shows it as you've defined it. If you don't, Google attempts to construct a breadcrumb from your URL structure — with varying accuracy.

The practical implication: even if your URL structure is clean (/tools/image-converter), you should still implement breadcrumb schema. The schema version gives you precise control over:

What names appear at each level
Which URLs each crumb points to
How many levels to show

URL-derived breadcrumbs sometimes produce odd results with dynamic routes, query parameters, or flat URL structures. Schema removes that uncertainty.

The Minimum Valid Breadcrumb Schema

Google requires at least two ListItem objects in a BreadcrumbList. A single-item list is invalid — breadcrumbs exist to show hierarchy, and hierarchy requires at least two levels. Each item must have position and name. The item (URL) is technically optional for the last item — since it represents the current page, Google infers it from the crawled URL.

For a two-level hierarchy (home → page):

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "About",
      "item": "https://example.com/about"
    }
  ]
}

For most tools and blog pages this is all you need. The current page is the last item. The homepage is always position 1.

Breadcrumb Schema for Deep Hierarchies

E-commerce sites, documentation sites, and blogs with categories often have three or four levels of hierarchy. Each level gets its own ListItem:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://shop.example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Electronics",
      "item": "https://shop.example.com/electronics"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Cameras",
      "item": "https://shop.example.com/electronics/cameras"
    },
    {
      "@type": "ListItem",
      "position": 4,
      "name": "Sony A7C II",
      "item": "https://shop.example.com/electronics/cameras/sony-a7c-ii"
    }
  ]
}

In search results: shop.example.com › Electronics › Cameras › Sony A7C II

Rules for deep hierarchies:

position values must be sequential integers starting at 1 — no gaps, no duplicates
Each intermediate level should have a real, accessible URL in item
The final item represents the current page — its item should match the canonical URL of the page

Field Reference

Field	Type	Required	Notes
`@type`	Text	Yes	Must be `"BreadcrumbList"`
`itemListElement`	Array	Yes	Array of `ListItem` objects
`ListItem.@type`	Text	Yes	Must be `"ListItem"`
`ListItem.position`	Integer	Yes	Sequential starting at 1. No gaps.
`ListItem.name`	Text	Yes	Human-readable label for this level
`ListItem.item`	URL	Conditional	Required for all items except the last. Recommended for the last item too.

That's the complete field set. Breadcrumb schema is deliberately simple — the value is in correct structure and real URLs, not in field variety.

The `item` Field: Should the Last Crumb Have a URL?

Technically, Google says item is not required for the last list item — since the last crumb represents the current page, Google can infer the URL from the page being crawled.

In practice: always include item for every crumb, including the last one.

Reasons:

Explicit is always safer than inferred
Some validators throw warnings when the last item has no item URL
It guarantees the correct canonical URL is associated with the last crumb, which matters for pages with URL parameters or multiple access paths

The last item's item URL should exactly match the canonical URL of the page — the same URL in your <link rel="canonical"> tag.

Matching Breadcrumb Schema to Visible Breadcrumb HTML

Google requires your breadcrumb structured data to correspond to an actual breadcrumb trail visible on the page. This is the most important rule and the most commonly violated one.

If your page has a visible breadcrumb navigation:

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    <li><a href="/tools">Tools</a></li>
    <li aria-current="page">Image Converter</li>
  </ol>
</nav>

Your JSON-LD must mirror this exactly. Same names, same URLs, same order.

If there's no visible breadcrumb on the page at all — Google may still process the schema, but the risk of a quality flag increases. The best implementation pairs HTML breadcrumb navigation (good for users) with JSON-LD breadcrumb schema (good for machines). They reference the same data.

Combining BreadcrumbList with Other Schema Types

A page can have both BreadcrumbList and another primary schema type. This is common and recommended:

<!-- Primary schema: what the page is about -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Image Converter",
  "url": "https://devtools.abect.com/png-to-jpg"
}
</script>

<!-- Navigation schema: where the page lives in the site -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://devtools.abect.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Image Tools",
      "item": "https://devtools.abect.com/image-tools"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "PNG to JPG",
      "item": "https://devtools.abect.com/png-to-jpg"
    }
  ]
}
</script>

Two separate <script> blocks — one for the primary content type, one for navigation. Don't merge them into a single object.

Alternative: Embedding BreadcrumbList Inside WebPage Schema

Some implementations nest the breadcrumb inside a WebPage schema using the breadcrumb property:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "PNG to JPG Converter",
  "url": "https://example.com/png-to-jpg",
  "breadcrumb": {
    "@type": "BreadcrumbList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "name": "Home",
        "item": "https://example.com"
      },
      {
        "@type": "ListItem",
        "position": 2,
        "name": "PNG to JPG",
        "item": "https://example.com/png-to-jpg"
      }
    ]
  }
}

This is valid schema.org syntax. Google supports both the standalone BreadcrumbList and the nested breadcrumb property approach. Use whichever fits your existing schema architecture — if you already have WebPage schema, nesting it is clean. If you don't, use a standalone block.

Implementation in Next.js (App Router)

For a tool site where every tool lives at a flat URL like /tool-name:

// components/BreadcrumbSchema.tsx

type BreadcrumbItem = {
  name: string
  url: string
}

export function BreadcrumbSchema({ items }: { items: BreadcrumbItem[] }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'BreadcrumbList',
    itemListElement: items.map((item, index) => ({
      '@type': 'ListItem',
      position: index + 1,
      name: item.name,
      item: item.url,
    })),
  }

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  )
}

Usage in a tool page:

// app/png-to-jpg/page.tsx

import { BreadcrumbSchema } from '@/components/BreadcrumbSchema'

export default function PngToJpgPage() {
  return (
    <>
      <BreadcrumbSchema
        items={[
          { name: 'Home', url: 'https://devtools.abect.com' },
          { name: 'PNG to JPG', url: 'https://devtools.abect.com/png-to-jpg' },
        ]}
      />
      {/* page content */}
    </>
  )
}

For category-based sites, pass the category as the middle item:

<BreadcrumbSchema
  items={[
    { name: 'Home', url: 'https://example.com' },
    { name: 'Electronics', url: 'https://example.com/electronics' },
    { name: 'Cameras', url: 'https://example.com/electronics/cameras' },
    { name: 'Sony A7C II', url: 'https://example.com/electronics/cameras/sony-a7c-ii' },
  ]}
/>

The component handles position automatically via the array index — one less thing to manually maintain.

Dynamic Breadcrumbs from URL Path

For sites where the URL structure directly maps to the breadcrumb hierarchy (clean, no vanity URLs), you can generate the breadcrumb schema dynamically from the current path:

// lib/breadcrumbs.ts

const LABELS: Record<string, string> = {
  '': 'Home',
  'tools': 'Tools',
  'image': 'Image Tools',
  'seo': 'SEO Tools',
  'png-to-jpg': 'PNG to JPG',
  'compress-jpg': 'Compress JPG',
  'meta-tags-generator': 'Meta Tags Generator',
}

export function buildBreadcrumbsFromPath(pathname: string, baseUrl: string) {
  const segments = pathname.split('/').filter(Boolean)

  const items = [{ name: 'Home', url: baseUrl }]

  let accumulatedPath = baseUrl
  for (const segment of segments) {
    accumulatedPath = `${accumulatedPath}/${segment}`
    items.push({
      name: LABELS[segment] ?? segment.replace(/-/g, ' '),
      url: accumulatedPath,
    })
  }

  return items
}

Usage:

import { usePathname } from 'next/navigation'
import { buildBreadcrumbsFromPath } from '@/lib/breadcrumbs'
import { BreadcrumbSchema } from '@/components/BreadcrumbSchema'

export default function Page() {
  const pathname = usePathname()
  const breadcrumbs = buildBreadcrumbsFromPath(pathname, 'https://devtools.abect.com')

  return (
    <>
      <BreadcrumbSchema items={breadcrumbs} />
      {/* content */}
    </>
  )
}

The LABELS map handles the display name for each segment — because png-to-jpg should display as "PNG to JPG", not "png to jpg". Segments without a defined label fall back to replacing hyphens with spaces.

Implementation in React (with react-helmet-async)

import { Helmet } from 'react-helmet-async'
import { useLocation } from 'react-router-dom'

function BreadcrumbSchema({ crumbs }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'BreadcrumbList',
    itemListElement: crumbs.map((crumb, i) => ({
      '@type': 'ListItem',
      position: i + 1,
      name: crumb.name,
      item: crumb.url,
    })),
  }

  return (
    <Helmet>
      <script type="application/ld+json">
        {JSON.stringify(schema)}
      </script>
    </Helmet>
  )
}

// Usage:
function ToolPage() {
  return (
    <>
      <BreadcrumbSchema
        crumbs={[
          { name: 'Home', url: 'https://example.com' },
          { name: 'Tools', url: 'https://example.com/tools' },
          { name: 'Image Converter', url: 'https://example.com/tools/image-converter' },
        ]}
      />
      {/* tool UI */}
    </>
  )
}

Implementation in WordPress

WordPress has a built-in breadcrumb trail concept via plugins (Yoast, RankMath) or theme functions. For manual implementation without plugins:

function add_breadcrumb_schema() {
  // Build breadcrumbs based on current page type
  $items = [];
  $position = 1;
  $base_url = home_url( '/' );

  // Always start with home
  $items[] = [
    '@type'    => 'ListItem',
    'position' => $position++,
    'name'     => 'Home',
    'item'     => $base_url,
  ];

  if ( is_category() || is_single() ) {
    $categories = get_the_category();
    if ( $categories ) {
      $cat = $categories[0];
      $items[] = [
        '@type'    => 'ListItem',
        'position' => $position++,
        'name'     => $cat->name,
        'item'     => get_category_link( $cat->term_id ),
      ];
    }
  }

  if ( is_single() || is_page() ) {
    $items[] = [
      '@type'    => 'ListItem',
      'position' => $position,
      'name'     => get_the_title(),
      'item'     => get_permalink(),
    ];
  }

  if ( count( $items ) < 2 ) return; // Don't output single-item breadcrumbs

  $schema = [
    '@context'        => 'https://schema.org',
    '@type'           => 'BreadcrumbList',
    'itemListElement' => $items,
  ];

  echo '<script type="application/ld+json">' . wp_json_encode( $schema ) . '</script>';
}
add_action( 'wp_head', 'add_breadcrumb_schema' );

For WooCommerce product pages, add a check for is_product() and use wc_get_breadcrumb() to get the WooCommerce breadcrumb data, then map it to the schema structure.

The 6 Most Common Breadcrumb Schema Mistakes

1. position values with gaps or duplicates

// Wrong — gap at 2, duplicate at 3
[
  { "position": 1, "name": "Home" },
  { "position": 3, "name": "Tools" },
  { "position": 3, "name": "Image Converter" }
]

// Correct — sequential, no gaps
[
  { "position": 1, "name": "Home" },
  { "position": 2, "name": "Tools" },
  { "position": 3, "name": "Image Converter" }
]

Google's validator flags non-sequential positions as errors. The position values must be consecutive integers starting at 1.

2. item URLs that don't match actual pages

Every URL in item must resolve to a real, accessible page. If /tools returns 404 but you include it as a breadcrumb item, Google will flag it. Only include levels that have real pages.

3. Breadcrumb schema that doesn't match the visible breadcrumb

If the page shows "Home > Tools > Converter" but the schema says "Home > Image > PNG Converter", it's a mismatch. Google cross-validates structured data against visible content. Keep them in sync — ideally by generating both from the same data source.

4. Using a single-item breadcrumb

A BreadcrumbList with only one item — just the current page — is pointless and may trigger a warning. Breadcrumbs are about hierarchy. If a page is the homepage, it doesn't need a breadcrumb. If it's one level deep, include at minimum Home + current page (two items).

5. Non-canonical item URLs

The item URLs must match the canonical URLs of those pages — the same URLs in their <link rel="canonical"> tags. Don't use trailing-slash variants, www vs non-www variants, or http vs https variants that differ from canonical. Inconsistency weakens the schema's value.

6. Putting @type: BreadcrumbList in the wrong place

A BreadcrumbList should not be nested inside properties of other schema types (except the breadcrumb property of WebPage). It should be a top-level JSON-LD object or nested specifically under WebPage.breadcrumb. Nesting it inside, say, a Product object is invalid.

Breadcrumb Best Practices for SEO

Beyond the structural requirements, a few content decisions affect how useful your breadcrumbs are:

Use meaningful names, not URLs. The name field is what users see in search results. "Image Tools" reads better than "image-tools" or "Image_Tools". Capitalize correctly and use the human-readable label, not the slug.

Reflect your actual URL structure. Your breadcrumb schema should mirror your URL hierarchy. If your URL is /tools/image/png-to-jpg, the breadcrumb should be Home › Tools › Image › PNG to JPG. Don't fabricate a hierarchy that doesn't exist in your URL structure — it confuses both users and crawlers.

Keep depth reasonable. Google will display breadcrumbs in search results, but very deep hierarchies (6+ levels) may be truncated. More than 4 levels is rare for most sites. If you find yourself at 5+ levels, consider whether your site architecture needs simplification.

Include breadcrumbs on every non-homepage page. Homepage doesn't need a breadcrumb. Every other page benefits from one — it's a small implementation cost with consistent SEO upside.

Validating Breadcrumb Schema

Google Rich Results Test — search.google.com/test/rich-results

Paste the page URL or raw JSON-LD. The test shows whether your BreadcrumbList is detected and lists any errors. Common errors include non-sequential positions, missing name fields, and unreachable item URLs.

Schema.org Validator — validator.schema.org

Validates the structural correctness of your JSON-LD. Use it to catch type errors that Google's tool sometimes misses.

Live search preview: After deploying, search your site by name in Google and check whether the URL display has changed to the breadcrumb format. This can take anywhere from a few days to a few weeks after Google re-crawls the page.

Google Search Console → Enhancements → Breadcrumbs

Shows real crawl data across your entire site. If breadcrumb schema is deployed at scale (e-commerce, blog), this report surfaces structural errors and which URLs are affected.

Wrapping Up

Breadcrumb schema is probably the least exciting thing to write about in structured data, but it's also the one with the most predictable payoff. Small field set, works on almost any site, you can see the effect in search results within days of the page being re-crawled. The things that break it are mechanical — sequential positions, real URLs, minimum two items — and they're all easily caught with the Rich Results Test before you deploy.

Before shipping:

position values start at 1 and increment by 1, no exceptions
Every URL in item must return a real page — 404s silently invalidate the crumb
Last item's URL must match the page's canonical URL exactly
If you have visible breadcrumb navigation on the page, the JSON-LD must match it

Generate breadcrumbs from a reusable component that shares its data with both the HTML navigation and the JSON-LD block. That way they're always in sync and you only update one place.

If you'd rather generate the BreadcrumbList JSON through a form: Breadcrumb Schema Generator. Free, no backend, runs in the browser.

Working with a site that has a flat URL structure with no real category hierarchy? Drop the setup in the comments — the "one level deep" breadcrumb case is more nuanced than it looks.

Why HEIC Breaks Websites — and How I Built a Browser-Only Converter to Fix It

Roman Popovych — Mon, 18 May 2026 16:13:10 +0000

My girlfriend was building a client site on Weblium. The client sent 200+ photos in HEIC format, kept adding more, swapping some out. Standard client behavior.

The problem: every single photo needed to be converted to WebP before it could go on the site. And the workflow she ended up with was painful — drag into Figma, export as PNG (because Figma can't export WebP natively), then convert PNG → WebP using an online tool. Two unnecessary steps for every photo. Figma plugins exist that handle this, but the good ones are paid or rate-limited, and using Figma as an image converter is overkill by definition.

I watched this happen and added two tools to my dev tools site: HEIC to JPG and HEIC to WebP. Drop files, batch convert, download ZIP. One step, zero uploads.

This post is about why HEIC is a problem for the web, how browser-based HEIC conversion actually works under the hood, and the specific decisions I made building it.

Why HEIC Exists and Why It Breaks Everything Outside Apple

Apple switched iPhones to HEIC by default with iOS 11 (2017). The motivation was pure storage efficiency: HEIC uses HEVC (H.265) as its image codec — the same codec used for 4K video streaming — inside an ISOBMFF container (the same container format as MP4).

The result is roughly 50% better compression than JPEG at the same perceptual quality. A 12MP iPhone photo that would be 5–8 MB as JPEG comes out at 2–4 MB as HEIC. For a phone with 64 GB of storage shooting thousands of photos, this matters enormously.

The problem is HEVC patent licensing. The codec is encumbered by patents from multiple pools (MPEG LA, HEVC Advance, Velos Media). Browser vendors haven't shipped a licensed HEVC decoder because the royalty structure is complex and contested. Safari gets away with it by delegating to the OS — macOS and iOS already have a licensed HEVC decoder for video playback, so Safari reuses it for images too. Chrome and Firefox don't have this path.

Browser HEIC support as of 2025

Browser	HEIC support	Notes
Safari (macOS / iOS)	Native	Delegates to OS HEVC decoder
Chrome	None	No licensed HEVC decoder
Firefox	None	No licensed HEVC decoder
Edge	None	Same engine as Chrome
Windows Photos	Paid codec	Requires Microsoft Store purchase

So if a client sends you HEIC photos and you upload them directly to a website, Chrome users (65%+ of global traffic) see nothing — the <img> tag simply fails to render.

The File Size Problem

Even if browser support weren't an issue, raw HEIC files are too heavy for web use.

2 MB per photo sounds reasonable until you have a gallery. A product page with 10 photos = 20 MB of images. Google's Core Web Vitals guidelines recommend keeping total page weight under 1–2 MB for fast LCP. A single unoptimized HEIC photo blows that budget.

WebP solves both problems: it's universally supported in modern browsers (97%+ of traffic including Safari 14+) and its compression is competitive with HEIC.

Format comparison for web delivery

Format	File size (12MP photo)	Browser support	Transparency	Best for
HEIC	2–4 MB	Safari only	Yes	iPhone storage
JPEG	4–8 MB	Universal	No	Legacy compatibility
PNG	12–25 MB	Universal	Yes	Lossless / editing
WebP	1–3 MB	97%+ (Safari 14+)	Yes	Web delivery
AVIF	1–2 MB	90%+	Yes	Next-gen web

WebP at quality 0.80 produces files 1–2 MB from a typical 12MP iPhone HEIC source — a 4–8× reduction compared to PNG and 50–75% smaller than the equivalent JPEG, with no visible quality difference on screen.

How Browser-Based HEIC Conversion Actually Works

The interesting constraint: I wanted zero uploads. Files never leave the user's device. This is a genuine privacy benefit when converting personal photos, medical images, or client work — but it means all decoding has to happen client-side.

HEIC decoding in a browser is non-trivial because, as established, Chrome and Firefox have no native HEIC support. There are two paths:

Path 1: Safari — native OS decoder via `createImageBitmap`

Safari can decode HEIC natively because it delegates to the macOS/iOS system codec. The browser exposes this through the standard createImageBitmap API:

const bitmap = await createImageBitmap(heicFile)
const canvas = document.createElement('canvas')
canvas.width = bitmap.width
canvas.height = bitmap.height
const ctx = canvas.getContext('2d')

// HEIC → JPEG: fill white background (HEIC supports transparency, JPEG doesn't)
if (outputMime === 'image/jpeg') {
  ctx.fillStyle = '#ffffff'
  ctx.fillRect(0, 0, canvas.width, canvas.height)
}

ctx.drawImage(bitmap, 0, 0)
bitmap.close()

const blob = await new Promise((resolve, reject) =>
  canvas.toBlob(
    b => (b ? resolve(b) : reject(new Error('toBlob failed'))),
    outputMime,
    0.8,
  )
)

Zero library cost, zero network requests, instant. Safari users get native performance.

Path 2: Chrome / Firefox — WebAssembly via `heic-to`

For Chrome and Firefox, I use heic-to — a library that bundles a WebAssembly build of libheif, which includes the libde265 software HEVC decoder.

The key decision here is lazy loading. The WASM bundle is ~1.2 MB. Loading it on every page visit — even for users who never drop a HEIC file — would be wasteful. Instead, I import it dynamically only when a HEIC file is actually detected:

const { heicTo } = await import('heic-to') // ~1.2 MB WASM, first use only
const blob = await heicTo({ blob: heicFile, type: outputMime, quality: 0.8 })

After the first conversion, the module is cached by the browser's module system. Subsequent conversions in the same session are instant.

The full conversion function

Putting it together — try native first, fall back to WASM:

const HEIC_QUALITY = 0.8

export async function convertHeicImage(file, mimeType) {
  try {
    // Safari: native path via OS HEVC decoder
    const bitmap = await createImageBitmap(file)
    const canvas = document.createElement('canvas')
    canvas.width = bitmap.width
    canvas.height = bitmap.height
    const ctx = canvas.getContext('2d')
    if (mimeType === 'image/jpeg') {
      ctx.fillStyle = '#ffffff'
      ctx.fillRect(0, 0, canvas.width, canvas.height)
    }
    ctx.drawImage(bitmap, 0, 0)
    bitmap.close()
    return new Promise((resolve, reject) =>
      canvas.toBlob(
        blob => (blob ? resolve(blob) : reject(new Error('Conversion failed'))),
        mimeType,
        HEIC_QUALITY,
      )
    )
  } catch {
    // Chrome/Firefox: lazy-load WASM decoder on first HEIC file
    const { heicTo } = await import('heic-to')
    return heicTo({ blob: file, type: mimeType, quality: HEIC_QUALITY })
  }
}

createImageBitmap throws on Chrome/Firefox when it encounters a HEIC file it can't decode — the catch block is the branch, not error handling for Safari failures.

Detecting HEIC Files Reliably

HEIC detection can't rely on MIME type alone. When users drag files from Windows Explorer, the browser often reports file.type as an empty string for HEIC because Windows doesn't register the MIME type without the paid codec. So the check needs to cover both:

const isHeic =
  file.type === 'image/heic' ||
  file.type === 'image/heif' ||
  file.name.toLowerCase().endsWith('.heic') ||
  file.name.toLowerCase().endsWith('.heif')

For the file input's accept attribute, I also include the extensions:

<input accept="image/heic,image/heif,.heic,.heif" />

Without the .heic,.heif fallback, the file picker on Windows hides HEIC files entirely because the OS doesn't know their MIME type.

Why Not PNG?

Initially I considered adding HEIC to PNG as well, but removed it. The math is ugly:

Conversion	Typical output (12MP photo)	vs HEIC source
HEIC → JPEG (q=0.80)	~1.5 MB	similar size
HEIC → WebP (q=0.80)	~1 MB	smaller
HEIC → PNG	~15 MB	10× larger

PNG is lossless — it stores every pixel precisely. A 12MP photo at 4 bytes/pixel = 144 MB raw data, which PNG's DEFLATE compression reduces to ~12–20 MB. HEVC achieves 2–4 MB on the same data by exploiting spatial and temporal redundancy across tiles. The difference is fundamental, not a tuning problem.

PNG makes sense as an intermediate format when you need to edit in Photoshop without introducing further compression artifacts. It makes no sense for web delivery. Keeping only JPG and WebP as outputs makes the tool's use case unambiguous.

One-Step vs Two-Step Conversion

A common mistake when converting HEIC for the web is going HEIC → JPEG → WebP. This applies lossy compression twice:

HEIC decode → JPEG encode (introduces DCT artifacts)
JPEG decode → WebP encode (compresses already-degraded data)

Converting HEIC → WebP directly decodes HEIC to a raw pixel buffer (lossless HEVC decode), then passes that buffer to the WebP encoder. Only one lossy step occurs — at the final encode — operating on full-quality pixel data from the HEIC source.

Two-step:  HEIC → (lossy) → JPEG → (lossy) → WebP   quality degrades twice
One-step:  HEIC → (lossless decode) → pixels → (lossy) → WebP

The Batch + ZIP Flow

For 200+ photos, converting one at a time isn't practical. The tool processes files concurrently and bundles results into a ZIP using JSZip:

async function buildZip(files) {
  const zip = new JSZip()
  for (const f of files) {
    if (f.resultBlob) {
      zip.file(f.name, f.resultBlob)
    }
  }
  return zip.generateAsync({ type: 'blob' })
}

The ZIP is generated entirely in memory and downloaded via a Blob URL — no server, no upload, no temp files anywhere outside the user's browser tab.

Stack and Constraints

The entire site is a static React app deployed on Vercel. No backend, no API routes, no file uploads. Every tool runs exclusively in the browser using:

Canvas API — image encode/decode and format conversion
File API — reading dropped or selected files
Blob URL API — in-memory file handling and downloads
WebAssembly (heic-to) — HEVC software decode for Chrome/Firefox, lazy-loaded

The HEIC conversion is the only tool on the site that loads external library code at runtime, and only when a HEIC file is actually dropped. Every other converter uses only browser-native APIs.

Try It

HEIC to WebP — smallest files, best for web
HEIC to JPG — maximum compatibility

Both support batch conversion and ZIP download. Source is vanilla React — no framework magic, just Canvas API and a WASM fallback.

If you've built something similar or have a better approach for client-side HEIC handling, I'd be curious to hear it in the comments.

Article Schema Markup: The Complete Guide to Structured Data for Blog Posts and Articles

Roman Popovych — Wed, 13 May 2026 13:15:33 +0000

There's a pattern I keep seeing. A developer spends real time writing a useful technical post — not SEO fluff, actual useful content — it gets indexed, and then they search for the exact topic it covers. Their competitor's article shows author attribution, a publish date, maybe a thumbnail image. Theirs shows a plain blue link with a meta description.

Article Schema is usually part of that gap. Not all of it — domain authority matters too — but structured data is the piece you actually control.

What's in this guide: the difference between Article, NewsArticle, and BlogPosting (it's not obvious), image size requirements that most guides get wrong, how author markup connects to E-E-A-T scoring, and working implementations for Next.js, React, and WordPress.

What Is Article Schema Markup?

Article Schema is a structured data type from schema.org/Article that tells search engines — in machine-readable JSON-LD format — that a page contains editorial content: an article, blog post, news story, or tutorial.

Without it, Google has to infer this from your HTML structure, heading hierarchy, and content signals. With it, you're stating it explicitly. That unlocks specific rich result types that aren't available to unstructured pages.

The script block sits in your <head> or <body>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your Article Title Here"
}
</script>

Article vs NewsArticle vs BlogPosting: Which Type to Use

Schema.org has a hierarchy for article content. Choosing the wrong type won't break anything, but choosing the right one signals your content category more accurately to Google.

Type	Use when	Rich result eligibility
`Article`	General editorial content, catch-all	Standard article results
`NewsArticle`	Time-sensitive news from a recognized publisher	Top Stories carousel, News tab
`BlogPosting`	Personal or company blog posts	Standard article results
`TechArticle`	Technical documentation, tutorials, how-to guides	Standard article results

Quick decision logic:

News publisher → NewsArticle
Dev blog, company blog → BlogPosting
Tutorials, API docs, technical how-tos → TechArticle
Everything else → Article

BlogPosting and TechArticle are both subtypes of Article, so they inherit all the same fields. NewsArticle has a few additional fields specific to journalism (like dateline and printEdition).

For most developers writing technical content on dev.to, personal blogs, or company engineering blogs: BlogPosting or TechArticle is the correct choice.

What Rich Results Article Schema Unlocks

Article structured data doesn't guarantee specific rich result features — Google decides what to display based on query context, site authority, and content freshness. But it makes you eligible for things that are otherwise impossible:

Feature	What appears	Requirements
Top Stories carousel	Large image + headline + source in a horizontal carousel	`NewsArticle`, AMP or fast page, news publisher
Article image in results	Thumbnail next to the snippet	`image` with correct dimensions
Author attribution	"By [Author Name]" in some result layouts	`author` with `@type: Person`
Breadcrumb in URL	`Site › Category › Article` format	`BreadcrumbList` schema (separate)
Sitelinks	Sub-links below the main result	`WebSite` schema + site authority
Paywalled content	Paywall indicator and preview snippet	`isAccessibleForFree` + `hasPart`

For an independent developer blog, the realistic wins are image display in search results and author E-E-A-T signals. Top Stories requires a news publisher relationship with Google. Sitelinks come from site authority, not schema. Know which goals are actually achievable before you start.

Google's Image Requirements for Article Rich Results

This is where most implementations fail silently. Google's Rich Results Test will show your schema as valid, but the image won't appear because it doesn't meet the dimension requirements.

The rules:

Minimum 50,000 pixels (width × height ≥ 50,000) — for example, 300×167px qualifies; anything smaller is ignored
Recommended aspect ratios: 16:9, 4:3, and 1:1 — provide all three for maximum placement flexibility across different result layouts
Format: JPG, PNG, WebP — avoid SVG or GIF
Must be crawlable — no auth walls, no X-Robots-Tag: noindex on the image URL
Must represent the article content — a logo, icon, or decorative image doesn't qualify

In practice, aim for much higher resolution than the technical minimum. A 1200×675px image (16:9, ~810K pixels) is the widely accepted practical target — it satisfies the pixel requirement with significant headroom and renders sharply across all display contexts.

The safest approach is to provide three image URLs covering all three aspect ratios:

"image": [
  "https://example.com/articles/js-tips-16x9.jpg",
  "https://example.com/articles/js-tips-4x3.jpg",
  "https://example.com/articles/js-tips-1x1.jpg"
]

If you only have one image, 1200×675px (16:9) is the practical sweet spot — well above the 50K pixel floor and covers the most common display context.

The Minimum Valid Article Schema

Google states explicitly: Article schema has no required properties. Instead, it recommends including the fields that apply to your content. In practice, headline, image, datePublished, and author are the four highest-impact fields — omitting any of them significantly reduces the chance of rich result display. Here's the smallest useful block:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How I Optimized My React App's Bundle Size by 60%",
  "image": "https://example.com/articles/bundle-optimization.jpg",
  "datePublished": "2026-05-08",
  "author": {
    "@type": "Person",
    "name": "Alex Johnson"
  }
}

This passes validation. But it's still the floor. A production article deserves the full set.

The Complete Article Schema: All Recommended Fields

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How I Optimized My React App's Bundle Size by 60%",
  "description": "A practical breakdown of code splitting, tree shaking, and lazy loading techniques that reduced a production React app's initial bundle from 1.8MB to 720KB.",
  "image": [
    "https://example.com/articles/bundle-optimization-16x9.jpg",
    "https://example.com/articles/bundle-optimization-4x3.jpg",
    "https://example.com/articles/bundle-optimization-1x1.jpg"
  ],
  "datePublished": "2026-05-08T09:00:00+00:00",
  "dateModified": "2026-05-08T09:00:00+00:00",
  "author": {
    "@type": "Person",
    "name": "Alex Johnson",
    "url": "https://example.com/authors/alex-johnson",
    "sameAs": [
      "https://twitter.com/alexjohnson",
      "https://github.com/alexjohnson",
      "https://linkedin.com/in/alexjohnson"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Dev Blog",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png",
      "width": 600,
      "height": 60
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/articles/react-bundle-optimization"
  },
  "url": "https://example.com/articles/react-bundle-optimization",
  "wordCount": 2400,
  "articleSection": "Performance",
  "keywords": ["React", "bundle size", "webpack", "code splitting", "performance"],
  "inLanguage": "en-US"
}

Field Reference: Required, Recommended, and Optional

Field	Type	Priority	Notes
`headline`	Text	Strongly recommended	Max 110 characters. Match your `<h1>`, not the `<title>`
`image`	URL or array	Strongly recommended	Min 50K pixels (width × height); 1200×675px is the practical target
`datePublished`	DateTime	Strongly recommended	ISO 8601: "2026-05-08" or "2026-05-08T09:00:00+00:00"
`author`	Person or Organization	Strongly recommended	Must include `name`; `url` strongly recommended; no job titles in `name`
`dateModified`	DateTime	Strongly recommended	Signals freshness to Google; update on significant edits
`publisher`	Organization	Strongly recommended	Required for Top Stories; include `logo`
`description`	Text	Recommended	Different from meta description — can be longer
`mainEntityOfPage`	WebPage	Recommended	Links the article to its canonical URL
`url`	URL	Recommended	Canonical URL of the article
`wordCount`	Integer	Optional	Helps Google understand content depth
`articleSection`	Text	Optional	Category name ("Technology", "Performance", "Security")
`keywords`	Text or array	Optional	Topic tags — not a ranking signal, but improves understanding
`inLanguage`	Text	Optional	BCP 47 language tag: "en-US", "uk", "de"
`isAccessibleForFree`	Boolean	Conditional	Required if content is paywalled

Author Markup and E-E-A-T

Google's E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) guidelines place heavy weight on knowing who wrote a piece of content, especially for health, finance, legal, and technical topics.

Author markup in structured data is one of the signals Google uses to evaluate this. A bare "name": "Alex" is valid but weak. A full author object with a linked author page and verified social profiles is significantly stronger:

"author": {
  "@type": "Person",
  "name": "Roman Popovych",
  "url": "https://devtools.abect.com/about",
  "sameAs": [
    "https://linkedin.com/in/yourprofile",
    "https://github.com/yourhandle",
    "https://twitter.com/yourhandle"
  ],
  "jobTitle": "Full-Stack Software Engineer",
  "worksFor": {
    "@type": "Organization",
    "name": "Freelance"
  }
}

Important: Google explicitly states that author.name should contain only the person's name — no job titles, honorifics (Dr., Prof.), or organizational affiliations. Put those in jobTitle and worksFor, not inside name. Violating this causes a validation warning.

The sameAs array is particularly valuable. It links your author entity to established profiles on platforms Google already trusts. This helps Google build a knowledge graph entity for you as an author — which strengthens the authority signal for everything you publish.

Your url should point to a dedicated author page (not your homepage) that includes your name, photo, bio, and links to your work. That page should also contain Person JSON-LD that mirrors this markup.

Multiple Authors

When an article has more than one author, author accepts an array:

"author": [
  {
    "@type": "Person",
    "name": "Alex Johnson",
    "url": "https://example.com/authors/alex"
  },
  {
    "@type": "Person",
    "name": "Maria Chen",
    "url": "https://example.com/authors/maria"
  }
]

For organizational authorship (when no individual author is credited), use Organization instead of Person:

"author": {
  "@type": "Organization",
  "name": "Example Engineering Team",
  "url": "https://example.com/team"
}

Implementation in Next.js (App Router)

In Next.js App Router, generate the JSON-LD object in the server component and inject it as a <script> tag. Don't generate it client-side — Google needs it in the initial HTML response.

// app/blog/[slug]/page.tsx

import { getPost } from '@/lib/posts'

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug)

  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'BlogPosting',
    headline: post.title,
    description: post.excerpt,
    image: post.coverImage,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt ?? post.publishedAt,
    author: {
      '@type': 'Person',
      name: post.author.name,
      url: `https://yoursite.com/authors/${post.author.slug}`,
    },
    publisher: {
      '@type': 'Organization',
      name: 'Your Blog Name',
      logo: {
        '@type': 'ImageObject',
        url: 'https://yoursite.com/logo.png',
        width: 600,
        height: 60,
      },
    },
    mainEntityOfPage: {
      '@type': 'WebPage',
      '@id': `https://yoursite.com/blog/${params.slug}`,
    },
    url: `https://yoursite.com/blog/${params.slug}`,
    wordCount: post.wordCount,
    articleSection: post.category,
    keywords: post.tags,
    inLanguage: 'en-US',
  }

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <article>
        <h1>{post.title}</h1>
        {/* article content */}
      </article>
    </>
  )
}

For generateMetadata, keep it separate — don't try to merge JSON-LD into the metadata object. They serve different purposes.

Implementation in React (with react-helmet-async)

import { Helmet } from 'react-helmet-async'

function BlogPost({ post }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'BlogPosting',
    headline: post.title,
    description: post.excerpt,
    image: post.coverImage,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt || post.publishedAt,
    author: {
      '@type': 'Person',
      name: post.author.name,
      url: post.author.profileUrl,
    },
    publisher: {
      '@type': 'Organization',
      name: 'Your Blog',
      logo: {
        '@type': 'ImageObject',
        url: 'https://yoursite.com/logo.png',
        width: 600,
        height: 60,
      },
    },
    mainEntityOfPage: {
      '@type': 'WebPage',
      '@id': post.url,
    },
    url: post.url,
  }

  return (
    <>
      <Helmet>
        <script type="application/ld+json">
          {JSON.stringify(jsonLd)}
        </script>
      </Helmet>
      <article>
        <h1>{post.title}</h1>
        {/* content */}
      </article>
    </>
  )
}

For React SPAs: Google processes JavaScript in a second crawl wave, which can delay indexing. If SEO matters for your blog, invest in SSR or static generation.

Implementation in WordPress (without a plugin)

WordPress with a classic theme doesn't add Article schema by default. Add it to functions.php for single post pages:

function add_article_schema() {
  if ( ! is_single() ) return;

  $author_id = get_post_field( 'post_author', get_the_ID() );

  $schema = [
    '@context'        => 'https://schema.org',
    '@type'           => 'BlogPosting',
    'headline'        => get_the_title(),
    'description'     => get_the_excerpt(),
    'image'           => get_the_post_thumbnail_url( get_the_ID(), 'full' ),
    'datePublished'   => get_the_date( 'c' ),
    'dateModified'    => get_the_modified_date( 'c' ),
    'url'             => get_permalink(),
    'author'          => [
      '@type' => 'Person',
      'name'  => get_the_author_meta( 'display_name', $author_id ),
      'url'   => get_author_posts_url( $author_id ),
    ],
    'publisher'       => [
      '@type' => 'Organization',
      'name'  => get_bloginfo( 'name' ),
      'logo'  => [
        '@type' => 'ImageObject',
        'url'   => get_site_icon_url( 512 ),
      ],
    ],
    'mainEntityOfPage' => [
      '@type' => 'WebPage',
      '@id'   => get_permalink(),
    ],
    'wordCount'       => str_word_count( get_the_content() ),
    'articleSection'  => implode( ', ', wp_list_pluck(
      get_the_category(), 'name'
    )),
    'keywords'        => implode( ', ', wp_list_pluck(
      get_the_tags() ?: [], 'name'
    )),
    'inLanguage'      => get_bloginfo( 'language' ),
  ];

  echo '<script type="application/ld+json">' . wp_json_encode( $schema ) . '</script>';
}
add_action( 'wp_head', 'add_article_schema' );

If you're using the Block Editor (Gutenberg), the get_the_content() function returns the full serialized block content. For word count, filter it through strip_tags( apply_filters( 'the_content', get_the_content() ) ) to get clean text.

The 6 Most Common Article Schema Mistakes

1. headline longer than 110 characters

Google truncates headlines beyond 110 characters and may not display the rich result at all. Keep it tight. If your <title> is longer, write a shorter headline — they don't have to be identical.

// Wrong — 130 characters
"headline": "A Very Thorough and Complete Investigation Into the Many Different Ways You Can Optimize Your JavaScript Bundle"

// Correct — 68 characters
"headline": "How to Optimize Your JavaScript Bundle: A Practical Guide"

2. Image too small

The single most common reason article images don't show in rich results. If your featured image is 800×450px, it won't qualify. Google requires minimum 1200px width. Always check with the Rich Results Test and look at the image dimensions in the report.

3. datePublished without dateModified

Google uses dateModified as a freshness signal. If you update an article significantly and don't update dateModified, Google may still treat it as the original publish date. Always update both when you make meaningful changes.

"datePublished": "2025-11-01T10:00:00+00:00",
"dateModified": "2026-05-08T14:30:00+00:00"

4. author with only a name and no URL

A name alone is a weak signal. Without an url pointing to an author page, Google can't verify the author entity. This reduces E-E-A-T value significantly for topics where authorship matters.

5. publisher missing the logo

For NewsArticle type specifically, a publisher logo is required for Top Stories eligibility. For BlogPosting it's recommended but not strictly required. Either way, leaving it out is a missed opportunity.

Logo requirements:

Rectangular (not square)
Max 600×60 pixels
Logo must be clearly visible on white background

6. headline not matching the visible <h1>

Google cross-validates your structured data against the visible page content. If your JSON-LD headline says one thing and your <h1> says something different, it's a signal inconsistency that can suppress rich results. They don't need to be character-for-character identical, but they should clearly refer to the same content.

Paywalled Content: The `isAccessibleForFree` Pattern

If your content is behind a subscription or paywall — even partially — you need to declare it. Presenting paywalled content as fully accessible in structured data is a Google policy violation.

For metered paywall (first N articles free):

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Exclusive: Inside the Next Generation of JavaScript Runtimes",
  "isAccessibleForFree": false,
  "hasPart": {
    "@type": "WebPageElement",
    "isAccessibleForFree": false,
    "cssSelector": ".paywall-content"
  }
}

Google will show a paywall indicator in search results and still index your content for ranking — it just won't show the full text in snippets.

Validating Article Schema

Google Rich Results Test — search.google.com/test/rich-results

Paste your URL or raw JSON-LD. The report will show which rich results your article is eligible for and list every error and warning. Pay attention to the image section — it shows the detected dimensions, which is the fastest way to confirm your image meets the 1200px minimum.

Schema.org Validator — validator.schema.org

More thorough than Google's tool. Will catch type errors, unknown properties, and structural issues that Google sometimes ignores.

Google Search Console → Search Appearance → Articles

After deploying and indexing, this shows real crawl data across all your article pages. Errors here directly affect performance. Monitor it 7–14 days after initial deployment and after any schema changes.

Validation checklist before publishing:

headline ≤ 110 characters
Image ≥ 1200px wide, aspect ratio 16:9 / 4:3 / 1:1
datePublished in ISO 8601 format
author includes name and url
publisher includes name and logo
No fields contradict visible page content

Article Schema and Search Console: What to Expect

After deploying Article schema across your blog, here's the realistic timeline:

Days 1–7: Google crawls and reprocesses indexed pages. No visible change in Search Console yet.

Days 7–14: Enhancements tab starts showing data. Expect some warnings — especially around images that don't meet dimension requirements.

Weeks 3–6: Rich results begin appearing in search listings for indexed articles. The first visible signs are usually article images in result snippets.

Month 2+: Meaningful CTR data accumulates. The comparison between pages with and without rich results becomes visible in the Performance report if you filter by article URLs.

Don't expect overnight changes. Structured data's impact on CTR is real but gradual — Google needs time to validate, index, and begin displaying the enhanced results.

Wrapping Up

Article schema won't move you from page 3 to page 1. But if you're already getting traffic, the author E-E-A-T signals are genuinely useful long-term, and getting your article image to display in search results is one of the few direct visual improvements you can make without changing rankings.

A few things to get right before shipping:

Right type first: BlogPosting for blog posts, TechArticle for tutorials and docs, NewsArticle only if you're an actual news publisher
Image needs to be at least 50K pixels (width × height) — in practice, target 1200×675px and you're safely above it
author.name is just the name — no job title, no "Dr.", no "CEO at Company" — put those in jobTitle and worksFor
Update dateModified when you make real edits, not just republish with the same date
Validate with the Rich Results Test before going live, and then check Search Console 2 weeks later to see how it processed across your actual crawled pages

If you'd rather generate the JSON-LD through a form instead of writing it by hand, there's a free browser-based tool: Article Schema Generator. No signup, everything runs locally.

Working with a schema setup that passes validation but still doesn't produce rich results? Drop the specifics in the comments — there are a few edge cases where that happens and they're usually diagnosable.

Product Schema Markup: The Complete Guide to Structured Data for E-Commerce Pages

Roman Popovych — Fri, 08 May 2026 14:49:16 +0000

You built a beautiful product page. Fast loading, clean design, great copy. Then you check Google Search Console and see your competitor's listing showing star ratings, price, and availability — right in the search results. Yours shows just a title and a meta description.

That gap is Product Schema Markup.

This guide covers everything: what it is, how Google uses it, which fields actually matter, common mistakes that silently break your rich results, and implementation examples for vanilla HTML, Next.js, and React.

What Is Product Schema Markup?

Product Schema is a vocabulary from schema.org/Product that you embed in your HTML to tell search engines — in a structured, machine-readable format — exactly what a product page is about.

It's implemented as JSON-LD (JavaScript Object Notation for Linked Data), a block of <script type="application/ld+json"> that sits in your page's <head> or <body>. Google, Bing, and other search engines parse this block and use it to display rich results — enhanced search listings that stand out from the standard blue link.

For product pages specifically, this means:

Star ratings displayed directly in search results
Price and currency
Stock availability ("In Stock" / "Out of Stock")
Review count
Product image in some placements

Why Product Schema Matters for SEO

Let me be direct: Product Schema is not a ranking factor. Google has confirmed this. Adding structured data doesn't push your page from position 12 to position 3.

What it does is improve CTR at whatever position you already hold.

A listing showing ⭐⭐⭐⭐⭐ 847 reviews · $49 · In Stock is visually larger, more trustworthy, and more clickable than a plain text result at the same position. Studies consistently show 10–30% CTR improvements for product pages with rich results enabled.

More clicks at the same position → more engagement signals → potentially better rankings over time. The effect is indirect but real.

There's also a second benefit: Google Shopping and merchant listings. If you connect your structured data with a Google Merchant Center account, your products can appear in Shopping tabs and price comparison features — without running paid ads.

What Google Can Show: Rich Result Types for Products

Not every field you add shows up. Google selects what to display based on query context and result layout. Here's what's eligible:

Feature	What it shows	Requires
Star ratings	⭐ 4.5 (847 reviews)	`aggregateRating` with `ratingValue` + `reviewCount`
Price	$49.99	`offers` → `price` + `priceCurrency`
Availability	"In stock"	`offers` → `availability`
Price drop	Strikethrough original price	`offers` → historical price data
Shipping	Free shipping info	`offers` → `shippingDetails`
Returns	Return policy	`offers` → `hasMerchantReturnPolicy`
Review snippets	Individual review text	`review` array

Google doesn't guarantee showing any of these — it's at their discretion. But you can't get them at all without the markup.

The Minimum Valid Product Schema

Google's Rich Results requirements state that a Product must have name plus at least one of: review, aggregateRating, or offers. Everything else is recommended but not required.

Here's the minimum that passes Google's Rich Results Test:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ergonomic Office Chair Pro",
  "offers": {
    "@type": "Offer",
    "price": "349.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

This is valid. It won't trigger rich results (no ratings), but it won't throw errors either. Think of it as the floor, not the target.

The Complete Product Schema: All Recommended Fields

Here's a production-ready example with every field Google recommends:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ergonomic Office Chair Pro",
  "description": "Fully adjustable ergonomic office chair with lumbar support, breathable mesh back, and 5-year warranty. Supports up to 150kg.",
  "image": [
    "https://example.com/images/chair-front.jpg",
    "https://example.com/images/chair-side.jpg",
    "https://example.com/images/chair-back.jpg"
  ],
  "sku": "CHAIR-ERG-PRO-001",
  "mpn": "EP-2024-001",
  "gtin13": "5901234123457",
  "brand": {
    "@type": "Brand",
    "name": "ErgoComfort"
  },
  "color": "Black",
  "material": "Mesh, Aluminum",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/ergonomic-chair-pro",
    "price": "349.00",
    "priceCurrency": "USD",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": {
      "@type": "Organization",
      "name": "Your Store Name"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "243",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "author": {
        "@type": "Person",
        "name": "Alex M."
      },
      "datePublished": "2026-03-15",
      "reviewBody": "Best office chair I've owned. My back pain is completely gone after switching to this."
    }
  ]
}

Field Reference: Required, Recommended, and Optional

Field	Type	Priority	Notes
`name`	Text	Required	Product name, not brand name
`offers`	Offer	Required*	At minimum price + currency
`aggregateRating`	AggregateRating	Strongly recommended	Enables star display in SERPs
`image`	URL or array	Strongly recommended	Min 160×90px, max 1920×1080px
`description`	Text	Recommended	Don't duplicate meta description verbatim
`sku`	Text	Recommended	Your internal SKU
`gtin` / `gtin13`	Text	Recommended	Barcode — helps Google identify the product globally
`brand`	Brand	Recommended	Separate `@type: Brand` object
`mpn`	Text	Recommended	Manufacturer part number
`color`	Text	Optional	Required for apparel rich results
`material`	Text	Optional
`priceValidUntil`	Date	Recommended	ISO 8601 format: "2026-12-31"
`itemCondition`	URL	Recommended	NewCondition, UsedCondition, RefurbishedCondition
`review`	Review array	Optional	Enables individual review snippets

*Required for rich results eligibility, along with aggregateRating or review

Multiple Offers: Handling Variants and Price Ranges

If your product has variants (sizes, colors) with different prices, you have two options.

Option 1: AggregateOffer — when variants have a price range:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Premium Wireless Headphones",
  "offers": {
    "@type": "AggregateOffer",
    "lowPrice": "199.00",
    "highPrice": "279.00",
    "priceCurrency": "USD",
    "offerCount": "3",
    "availability": "https://schema.org/InStock"
  }
}

Google will display something like "$199 – $279" in search results.

Option 2: Array of Offer objects — when you want to be explicit about each variant:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Premium Wireless Headphones",
  "offers": [
    {
      "@type": "Offer",
      "name": "Black — Standard",
      "price": "199.00",
      "priceCurrency": "USD",
      "availability": "https://schema.org/InStock"
    },
    {
      "@type": "Offer",
      "name": "White — Limited Edition",
      "price": "279.00",
      "priceCurrency": "USD",
      "availability": "https://schema.org/LimitedAvailability"
    }
  ]
}

Implementation in Next.js (App Router)

In Next.js App Router, inject JSON-LD using a <script> tag directly in the page component. Build the object server-side — JSON-LD must be present in the initial HTML for Google to parse it during crawl. Client-side rendered structured data is unreliable.

// app/products/[slug]/page.tsx

export default async function ProductPage({ params }) {
  const product = await getProduct(params.slug)

  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    description: product.description,
    image: product.images,
    sku: product.sku,
    brand: {
      '@type': 'Brand',
      name: product.brand,
    },
    offers: {
      '@type': 'Offer',
      price: product.price.toString(),
      priceCurrency: product.currency,
      availability: product.inStock
        ? 'https://schema.org/InStock'
        : 'https://schema.org/OutOfStock',
      url: `https://yourstore.com/products/${params.slug}`,
      priceValidUntil: '2026-12-31',
      itemCondition: 'https://schema.org/NewCondition',
    },
    aggregateRating: product.rating
      ? {
          '@type': 'AggregateRating',
          ratingValue: product.rating.average.toString(),
          reviewCount: product.rating.count.toString(),
          bestRating: '5',
        }
      : undefined,
  }

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      {/* rest of page */}
    </>
  )
}

Implementation in React (with react-helmet-async)

For React SPAs, use react-helmet-async to inject the script tag into <head>. Note: Google can render JavaScript, but it's a two-wave crawl process — SSR or static generation is always preferable for structured data reliability.

import { Helmet } from 'react-helmet-async'

function ProductPage({ product }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    description: product.description,
    image: product.image,
    offers: {
      '@type': 'Offer',
      price: product.price.toString(),
      priceCurrency: 'USD',
      availability: product.available
        ? 'https://schema.org/InStock'
        : 'https://schema.org/OutOfStock',
    },
    aggregateRating: {
      '@type': 'AggregateRating',
      ratingValue: product.rating.toString(),
      reviewCount: product.reviewCount.toString(),
      bestRating: '5',
    },
  }

  return (
    <>
      <Helmet>
        <script type="application/ld+json">
          {JSON.stringify(jsonLd)}
        </script>
      </Helmet>
      {/* page content */}
    </>
  )
}

Implementation in WordPress (without a plugin)

If you're managing a WooCommerce store and want full control without relying on Yoast or RankMath generating the schema for you, add this to your functions.php:

function add_product_schema() {
  if ( ! is_product() ) return;

  global $product;

  $schema = [
    '@context'    => 'https://schema.org',
    '@type'       => 'Product',
    'name'        => get_the_title(),
    'description' => wp_strip_all_tags( $product->get_short_description() ),
    'image'       => wp_get_attachment_url( $product->get_image_id() ),
    'sku'         => $product->get_sku(),
    'offers'      => [
      '@type'         => 'Offer',
      'price'         => $product->get_price(),
      'priceCurrency' => get_woocommerce_currency(),
      'availability'  => $product->is_in_stock()
        ? 'https://schema.org/InStock'
        : 'https://schema.org/OutOfStock',
      'url'           => get_permalink(),
    ],
  ];

  echo '<script type="application/ld+json">' . wp_json_encode( $schema ) . '</script>';
}
add_action( 'wp_head', 'add_product_schema' );

This gives you precise control over every field instead of relying on plugin heuristics that may add properties you don't need or miss ones you do.

The 7 Most Common Product Schema Mistakes

These are the errors that pass syntax validation but fail Google's rich result requirements — the silent killers.

1. Price as a number instead of a string

// Wrong — will trigger a Google validation warning
"price": 49.99

// Correct
"price": "49.99"

Schema.org expects price as a string. A bare number causes warnings in Rich Results Test and may suppress the price display.

2. Missing priceCurrency

Price without currency is meaningless. Google requires both fields together. If priceCurrency is absent, the price won't display in rich results even if price is correctly formatted.

3. Relative URLs for availability

// Wrong — Google doesn't recognize plain text values
"availability": "InStock"

// Correct — must be a full schema.org URI
"availability": "https://schema.org/InStock"

Valid availability values: https://schema.org/InStock, https://schema.org/OutOfStock, https://schema.org/PreOrder, https://schema.org/LimitedAvailability, https://schema.org/Discontinued.

4. Fabricated aggregateRating data

Google's quality guidelines explicitly prohibit fake or incentivized reviews in structured data. Using fabricated ratings can result in rich result suppression or a manual penalty that affects your entire domain.

5. Including aggregateRating with zero reviews

If you have no reviews yet, don't include the aggregateRating block at all. An aggregateRating with reviewCount: 0 throws a validation error. Wait until you have real data.

6. priceValidUntil in the past

If your priceValidUntil date has expired, Google may suppress the price in rich results. Either update it regularly (build it into your CMS workflow) or set it to a far-future date if your pricing is stable.

7. Structured data that contradicts visible page content

The most important rule: your JSON-LD must match what's actually on the page. If the page shows $49 but JSON-LD says $39, or your page says "Out of Stock" but your schema says InStock — Google will flag it. This can result in a manual action that removes all rich results across your entire site.

Validating Your Product Schema

Three tools, used in this order:

1. Google Rich Results Test — search.google.com/test/rich-results

The official tool. Paste a URL or raw JSON-LD, see exactly which rich results are eligible and what errors exist. Always run this before deploying.

2. Schema.org Validator — validator.schema.org

Validates against the full schema.org specification. More strict than Google's tool. Use it to catch type mismatches and unknown properties that Google's tool sometimes ignores.

3. Google Search Console → Enhancements → Shopping

Shows real crawl data for your live pages after Google indexes them. Errors here are what actually affect your search performance — not just lab test results. Check this 7–14 days after deploying changes.

Validation workflow:

Build JSON-LD locally and test with Rich Results Test
Fix all errors and warnings (warnings matter for products)
Deploy to production
Request indexing in Search Console
Check Enhancements tab after one to two weeks

When Product Schema Won't Help

Schema markup is a tool, not a shortcut. It won't move the needle if:

Your page has no rating data. You can add every field perfectly, but without aggregateRating or review, Google won't show stars. That's the single most impactful rich result for product pages.
You're ranking on page 3+. Rich results are displayed in the listing, but no one sees page 3 results. Fix rankings first, then optimize the snippet.
Your structured data contradicts page content. Google cross-validates JSON-LD against visible content. Mismatches get suppressed.
You're in a YMYL category without domain authority. Health supplements, financial products, medical devices. Google applies extra scrutiny and requires demonstrated expertise and trustworthiness before showing rich results.

Summary

Product Schema Markup is one of the few technical SEO changes with a directly measurable outcome: your search listing either gets rich results or it doesn't. The implementation is straightforward, the validation tooling is free and official, and the potential CTR upside is real.

The practical checklist:

Include name, offers (price + currency + availability), and aggregateRating at minimum
Use full schema.org URIs for availability and itemCondition — not plain text keywords
Always validate against the Rich Results Test before deploying
Keep priceValidUntil current — set a reminder if needed
Never put data in JSON-LD that contradicts what's visible on the page
For Next.js: build the object server-side, not in a client component

If you want to skip the JSON construction entirely and generate valid Product Schema through a form interface — with live preview, Google eligibility check, and missing field warnings — there's a free browser-based tool here: Product Schema Generator. No signup, no backend, everything runs locally in the browser.

Found an error or have a question? Drop it in the comments — schema edge cases are genuinely interesting to dig into.

Are Open Graph Tags Important for SEO and Social Sharing? I Ignored Them Until My Link CTR Started Dropping

Roman Popovych — Mon, 04 May 2026 14:39:14 +0000

****I spent weeks optimizing:

performance
Lighthouse scores
bundle size
lazy loading
SEO structure

…while completely ignoring the thing users actually saw first:

The link preview.

Not the website itself.

The preview card inside:

Telegram
Discord
LinkedIn
X
Slack
Facebook
Reddit

And after building more browser-based developer tools, I realized something important:

A broken or low-quality Open Graph setup can reduce clicks before your page even loads.

What Are Open Graph Tags?

Open Graph tags (OG tags) are metadata tags placed inside the

of an HTML document.

They control how your page appears when shared on social media platforms and messaging apps.

A typical Open Graph setup looks like this:

Without these tags, platforms attempt to generate previews automatically.

Sometimes they succeed.

Often they don’t.

Why Open Graph Tags Matter

Most developers think users evaluate:

code quality
architecture
performance
frameworks
backend design

But in reality, most users make an emotional decision within seconds.

Especially when they discover your product through a shared link.

That means your Open Graph preview becomes:

your first impression
your packaging
your ad creative
your social thumbnail

Before users even visit the page.

Do Open Graph Tags Affect SEO?

Technically, Open Graph tags are not direct Google ranking factors.

Adding OG tags alone will not improve your rankings.

But they absolutely affect SEO indirectly.

Better previews often lead to:

higher CTR
more shares
better engagement
improved distribution
more backlinks
stronger brand recognition

And those signals matter long-term.

Especially for:

SaaS products
side projects
indie hacker tools
AI products
blogs
developer utilities
startup landing pages

Why My Shared Links Started Performing Worse

At first I assumed all my pages were fine because:

they loaded fast
had good SEO structure
worked correctly

But then I noticed something strange.

Some tools consistently got fewer clicks when shared in communities.

Same audience.
Same platform.
Same quality.

Different engagement.

After manually testing previews, the problem became obvious.

Some pages displayed:

stretched logos
random screenshots
duplicated titles
broken image crops
missing descriptions
favicon previews

One page even rendered a tiny navigation icon instead of the actual product image.

That instantly makes a product look unfinished.

The Most Important Open Graph Tags

Here’s the minimum recommended OG setup for modern websites.

Tag Purpose
og:title Main preview title
og:description Preview description
og:image Social preview image
og:url Canonical page URL
og:type Content type

For X/Twitter, you should also include:

Why og:image Is the Most Important Tag

If you only optimize one thing, optimize the preview image.

The image controls:

visual quality
branding
attention
recognizability
perceived professionalism

Bad OG image examples:

blurry screenshots
giant logos
unreadable text
low contrast
random crops
empty backgrounds

Good OG image examples:

clear title
recognizable action
strong hierarchy
readable typography
product-focused design

Recommended OG Image Size

After testing previews across multiple platforms, this specification worked most consistently:

Property Recommended Value
Resolution 1200×630
Aspect ratio 1.91:1
Format PNG or JPG
File size Under 300KB
URL type Absolute URL

I also stopped using WebP for OG images because some platforms still render it inconsistently.

Common Open Graph Mistakes

Missing og:image

This is the most common issue.

Without it, platforms attempt automatic image detection.

Results are unpredictable.

Using Relative URLs

Bad:

Better:

Some scrapers fail to resolve relative paths correctly.

Reusing the Same Image Everywhere

Using one generic preview image for every page reduces:

recognizability
contextual relevance
CTR potential

Especially for tool collections and blogs.

Large Image Files

Oversized images can:

slow scraper processing
fail loading
reduce rendering consistency

Forgetting Platform Cache

Platforms cache previews aggressively.

Updating your metadata does not always refresh previews immediately.

This causes many developers to think their OG tags are broken when the issue is actually cache persistence.

Why Different Platforms Render OG Tags Differently

One thing I learned quickly:

Every platform behaves differently.

Platform Common Problem
Discord Aggressive caching
Telegram Delayed preview refresh
LinkedIn Unexpected image crops
Facebook Metadata cache persistence
X Strict image behavior

That means testing matters.

Not just browser inspection.

How Social Scrapers Actually Work

Most platforms use automated crawlers called scrapers.

These bots:

Visit your page
Parse metadata
Extract Open Graph tags
Cache preview information
Generate preview cards

If your metadata is:

missing
malformed
blocked
delayed
dynamically injected incorrectly

…your preview may fail entirely.

This is especially common in poorly configured SPA applications.

Why Client-Side Injected OG Tags Often Fail

Many modern frontend frameworks render metadata dynamically on the client.

Problem:
Social scrapers often do not execute JavaScript fully.

That means:

client-side injected metadata may never appear
previews become incomplete
social cards break

This is why server-side rendering (SSR), static generation (SSG), or proper prerendering matter for social metadata.

Especially in:

React apps
Next.js projects
Vue SPAs
Angular applications

Open Graph Tags vs Standard SEO Meta Tags

A lot of developers confuse these systems.

Meta Type Purpose
title Browser + search engine title
meta description Search engine snippet
Open Graph tags Social sharing previews
Twitter tags X/Twitter preview customization

They work together, but they are not identical.

Why OG Tags Matter More for Modern Distribution

Years ago, discovery mostly happened through:

Google search
directories
homepage traffic

Now products spread through:

Discord communities
Slack workspaces
Telegram chats
Reddit threads
LinkedIn posts
X reposts

That changes everything.

Because now users often encounter:
the preview first,
the website second.

The Psychological Side of Link Previews

Users subconsciously associate polished previews with:

trust
product maturity
technical quality
legitimacy

Even before opening the page.

A broken preview creates friction immediately.

Especially for:

startups
SaaS tools
freelance portfolios
browser utilities
AI products

The preview becomes part of your branding system.

Why I Started Generating Unique OG Images

At first I reused one generic image everywhere.

But once the number of pages increased, the problem became obvious.

A tool collection with:

identical previews
repeated branding
no contextual differentiation

…becomes visually invisible in feeds.

So I started generating dedicated OG images for every page:

PNG to JPG Converter
JSON Formatter
Base64 Encoder
Image Compressor
Markdown Previewer

This immediately improved:

visual consistency
recognizability
perceived product quality

Dynamic OG Generation Scales Better

Manually designing every social preview becomes painful at scale.

Especially for:

blogs
SaaS products
documentation
changelogs
developer tool directories

That’s why dynamic OG generation eventually becomes necessary.

Instead of creating every image manually in Figma, automated generation allows:

reusable templates
scalable workflows
consistent branding
faster publishing

Privacy Matters More Than People Think

One thing I kept consistent with my entire tool suite:

Everything runs locally in the browser.

No backend.
No uploads.
No external image processing.

That matters because OG generation often includes:

unreleased product names
client assets
launch visuals
internal screenshots

Keeping everything client-side improves both privacy and workflow speed.

Best Tools for Testing Open Graph Tags

These tools help debug broken previews:

Tool Purpose
Facebook Sharing Debugger Refresh Facebook previews
X Card Validator Validate Twitter/X cards
LinkedIn Post Inspector Test LinkedIn rendering
Discord preview testing Verify embed behavior
Telegram chats Real-world validation

Always test across multiple platforms.

Final Thoughts

I used to think Open Graph tags were optional polish.

Now I consider them foundational infrastructure for modern web products.

Not because they directly improve rankings.

But because they directly affect:

distribution
click-through rate
social visibility
brand perception
trust

And in many cases, your shared preview is the first version of your product users ever experience.

If that preview looks broken, random, or unfinished, users may never open the page at all.

That realization completely changed how I approach metadata and social sharing.

So I recently added a dedicated Open Graph image generator to my privacy-first browser tool suite:

https://devtools.abect.com/og-image-generator

Everything works locally in the browser with no backend or uploads.

How I Built a Privacy-First Browser Tool Suite to Fix My Own Freelance Workflow (No Backend, No Uploads, No Nonsense)

Roman Popovych — Sun, 26 Apr 2026 14:47:48 +0000

Ever had one of those freelance days where you spend more time switching between tabs than actually building something?

Client sends over 10 raw photos, 3MB each. No logo. No favicon. SEO meta tags that need to be written from scratch. You open one site to convert images, another to compress them, a third to generate favicons. One of them has a casino ad that takes up half the screen. Another one slaps a watermark on your file without warning. A third one probably uploads your images somewhere and you have no idea where they go.

I counted once. Six different sites for one client project. Before writing a single line of code.

At some point I just got tired of it and decided to build my own thing. Not because I thought it would be easy, but because I had 1-2 hours after work and nothing better to do with them.

That project is devtools.abect.com — a set of free browser-based tools for developers. Image converters, compressors, favicon generator, SEO meta tag generator. No backend, no account, no watermarks, no ads.

This is the story of how it works under the hood.

The Problem with "Free" Online Tools

Most online converters work the same way: you pick a file, it gets uploaded to their server, processed somewhere you can't see, and sent back to you. You just hand over your client's assets to a random server and hope for the best.

For personal photos, maybe fine. For client work — internal screenshots, unreleased brand assets, documents — that's a different story.

Beyond privacy, there's the UX problem. File size limits. Daily caps on the free tier. Watermarks you don't notice until you've already sent the file to the client. Ads that make the page unusable on mobile.

I wanted something that just works. No friction, no accounts, no surprises.

The Architecture: Why Zero Backend?

The core idea was simple: run everything in the browser.

No server means no uploads. No uploads means no privacy risk. No server also means no hosting costs, no infrastructure to maintain, and no rate limits to worry about.

Modern browsers are surprisingly capable. Between the Canvas API, File API, Blob URLs, and Web Crypto, you can do serious image processing entirely client-side. The question wasn't "can this be done?" but "how far can this actually go?"

Turns out — pretty far.

Here is the full stack of browser APIs the project uses, and what each one actually does:

Canvas API — the core of every image operation. Draws the image onto an off-screen canvas, applies transformations, and exports to the target format via toBlob(). Every converter, compressor, and the favicon renderer goes through this pipeline.

File API — reads files dropped or selected by the user directly in the browser. Files never touch a network request. They go straight into the Canvas pipeline.

Blob URL API — creates in-memory object URLs for previews and downloads. URL.createObjectURL() gives you an instant download link from raw binary data, no server round-trip required.

Web Crypto API — generates unique IDs for each file in a batch queue using crypto.randomUUID(). Stateless, no tracking, collision-proof.

JSZip — assembles ZIP archives from Blob objects inside the browser tab. Batch download of 20 converted images: one ZIP, zero server calls.

TypedArrays + DataView — used specifically for .ico file generation. More on this in a second.

Everything verifiable. Open DevTools, go to the Network tab, drop a file in. You will see zero outgoing file transfers.

How the Image Pipeline Actually Works

The Canvas-based image conversion pipeline is straightforward once you understand it, but there are a few non-obvious details.

async function convertImage(file, targetFormat, quality = 0.85) {
  // Step 1: load the file into an HTMLImageElement
  const bitmap = await createImageBitmap(file);

  // Step 2: draw onto an off-screen canvas
  const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
  const ctx = canvas.getContext('2d');
  ctx.drawImage(bitmap, 0, 0);

  // Step 3: export to target format
  const blob = await canvas.convertToBlob({
    type: `image/${targetFormat}`,
    quality: quality,
  });

  return blob;
}

OffscreenCanvas is the key detail here. It runs off the main thread so the UI stays responsive when processing a batch of 20 images. No freezing, no spinner blocking the page.

For compression, the same pipeline applies — same format in and out, just a lower quality value. The live preview before download is just a second canvas render at the target quality, displayed immediately.

One edge case that took some debugging: AVIF export via convertToBlob has inconsistent browser support. Chrome supports it, Firefox does not. The solution was a format support detection step at initialization:

async function detectSupportedFormats() {
  const canvas = document.createElement('canvas');
  canvas.width = canvas.height = 1;

  const formats = ['webp', 'avif', 'image/jpeg'];
  const supported = {};

  for (const fmt of formats) {
    const dataURL = canvas.toDataURL(`image/${fmt}`);
    supported[fmt] = dataURL.startsWith(`data:image/${fmt}`);
  }

  return supported;
}

If AVIF is not supported, the option is hidden from the UI rather than shown as a broken feature.

The Interesting Part: Building .ico Files from Scratch

This was the part I did not expect to spend time on.

Most favicon generators either use a library or just output a PNG and rename it .ico. Neither approach is quite right. A proper .ico file is a binary container format that can hold multiple image sizes in a single file. Browsers pick the right one depending on context.

The Canvas API cannot produce .ico files natively. toBlob() supports image/png, image/jpeg, image/webp — that's it. So building a multi-size .ico had to be done manually with TypedArrays and DataView.

Here is the structure of an ICO file:

[ICONDIR header]       — 6 bytes
[ICONDIRENTRY × N]     — 16 bytes per image
[Image data × N]       — PNG or BMP blobs

In code:

function buildIcoFile(pngBlobs) {
  // pngBlobs: array of { blob, width, height }
  const count = pngBlobs.length;
  const headerSize = 6 + count * 16;

  // calculate total buffer size
  const totalSize = headerSize + pngBlobs.reduce((acc, { blob }) => acc + blob.size, 0);
  const buffer = new ArrayBuffer(totalSize);
  const view = new DataView(buffer);

  // ICONDIR header
  view.setUint16(0, 0, true);      // reserved, must be 0
  view.setUint16(2, 1, true);      // type: 1 = ICO
  view.setUint16(4, count, true);  // number of images

  let dataOffset = headerSize;

  pngBlobs.forEach(({ width, height, size }, i) => {
    const entryOffset = 6 + i * 16;

    view.setUint8(entryOffset,     width  < 256 ? width  : 0);
    view.setUint8(entryOffset + 1, height < 256 ? height : 0);
    view.setUint8(entryOffset + 2, 0);   // color palette count (0 = no palette)
    view.setUint8(entryOffset + 3, 0);   // reserved
    view.setUint16(entryOffset + 4, 1, true); // color planes
    view.setUint16(entryOffset + 6, 32, true); // bits per pixel
    view.setUint32(entryOffset + 8, size, true);       // image data size
    view.setUint32(entryOffset + 12, dataOffset, true); // offset from file start

    dataOffset += size;
  });

  // write PNG blobs into the buffer after the directory
  // (requires converting each Blob to ArrayBuffer via FileReader or arrayBuffer())
  return buffer;
}

Each PNG is rendered at 16x16, 32x32, 48x48, and 64x64 via Canvas, then packed into a single ICO container. The result downloads as a proper multi-resolution favicon — same as what a desktop application would produce.

This was the part that required actually reading the ICO spec and working through the binary layout by hand. No library. Just DataView, a lot of offset arithmetic, and eventually a working .ico file.

What I Learned About AI-Assisted Development

The entire project was built with Claude Code. I set a rule at the start: no hand-written code. I wanted to see how far that could go.

It went pretty far — but not in the way I expected.

The AI handles boilerplate well. Repetitive logic, utility functions, component scaffolding — fast and clean. Where it struggles is multi-step browser API chains with edge cases. The Canvas pipeline for batch processing with OffscreenCanvas required several correction rounds. The ICO binary layout had to be verified offset by offset.

The role I ended up playing was less "developer" and more "spec reader + QA." I read the ICO binary format documentation, checked the Canvas API behavior across browsers, and caught the places where the output was technically valid but practically wrong. The AI wrote the code; I told it why it was wrong and what to fix.

That's a different workflow, not a better or worse one. Just different.

SEO Structure: One Tool, One URL

One decision that shaped the whole project was URL structure.

The obvious approach is a single converter page: /convert?from=png&to=jpg. One page, one component, all formats handled by query params.

I went the other direction: /png-to-jpg, /jpg-to-webp, /webp-to-avif — each format pair gets its own page with its own content, meta tags, and JSON-LD schema.

The reasoning: someone searching "png to jpg online" is not the same person as someone searching "compress webp file." Different intent, different content, different page. A generic converter page captures neither well.

Each tool page has:

A HowTo JSON-LD schema with numbered steps
A FAQPage schema with 8-9 questions (same content renders as the visible FAQ, no duplication)
A format comparison table (good for featured snippet capture)
Implementation guides with code examples for React, Next.js, Vue, and WordPress

Whether this actually moves rankings is an open question. I started tracking in Google Search Console after the SEO overhaul in late April. Will share results in a follow-up post once there is enough data to say anything useful.

What's Next

Right now the project has 26 tools. A few things I'm weighing for what comes next:

JSON-LD Generator — fill in a form, get valid structured data for any schema type. Useful for the same workflow that led to building the meta tag generator.
SVG Optimizer — strip unnecessary metadata and reduce file size client-side. SVGO in the browser.
CSS Gradient Generator — simple, high search volume, fits the browser-based model well.

The constraint is time, not ideas. One new tool per week is realistic while keeping the existing ones properly maintained.

Try It

devtools.abect.com — free, no account, no watermarks, no ads. Works offline after the first load.

If you find a bug or something behaves wrong in your browser, I want to know. And if you have a tool you keep opening a separate site for — tell me in the comments. That's basically how this whole project started.

DEV Community: Roman Popovych

Breadcrumb Schema Markup: The Complete Guide to Structured Data for Site Navigation

What Is Breadcrumb Schema?

What Breadcrumb Schema Looks Like in Search Results

When Google Shows Breadcrumbs in Search Results

The Minimum Valid Breadcrumb Schema

Breadcrumb Schema for Deep Hierarchies

Field Reference

The item Field: Should the Last Crumb Have a URL?

Matching Breadcrumb Schema to Visible Breadcrumb HTML

Combining BreadcrumbList with Other Schema Types

Alternative: Embedding BreadcrumbList Inside WebPage Schema

Implementation in Next.js (App Router)

Dynamic Breadcrumbs from URL Path

Implementation in React (with react-helmet-async)

Implementation in WordPress

The 6 Most Common Breadcrumb Schema Mistakes

Breadcrumb Best Practices for SEO

Validating Breadcrumb Schema

Wrapping Up

Why HEIC Breaks Websites — and How I Built a Browser-Only Converter to Fix It

Why HEIC Exists and Why It Breaks Everything Outside Apple

Browser HEIC support as of 2025

The File Size Problem

Format comparison for web delivery

How Browser-Based HEIC Conversion Actually Works

Path 1: Safari — native OS decoder via createImageBitmap

Path 2: Chrome / Firefox — WebAssembly via heic-to

The full conversion function

Detecting HEIC Files Reliably

Why Not PNG?

One-Step vs Two-Step Conversion

The Batch + ZIP Flow

Stack and Constraints

Try It

Article Schema Markup: The Complete Guide to Structured Data for Blog Posts and Articles

What Is Article Schema Markup?

Article vs NewsArticle vs BlogPosting: Which Type to Use

What Rich Results Article Schema Unlocks

Google's Image Requirements for Article Rich Results

The Minimum Valid Article Schema

The Complete Article Schema: All Recommended Fields

Field Reference: Required, Recommended, and Optional

Author Markup and E-E-A-T

Multiple Authors

Implementation in Next.js (App Router)

Implementation in React (with react-helmet-async)

Implementation in WordPress (without a plugin)

The 6 Most Common Article Schema Mistakes

Paywalled Content: The isAccessibleForFree Pattern

Validating Article Schema

Article Schema and Search Console: What to Expect

Wrapping Up

Product Schema Markup: The Complete Guide to Structured Data for E-Commerce Pages

What Is Product Schema Markup?

Why Product Schema Matters for SEO

What Google Can Show: Rich Result Types for Products

The Minimum Valid Product Schema

The Complete Product Schema: All Recommended Fields

Field Reference: Required, Recommended, and Optional

Multiple Offers: Handling Variants and Price Ranges

Implementation in Next.js (App Router)

Implementation in React (with react-helmet-async)

Implementation in WordPress (without a plugin)

The 7 Most Common Product Schema Mistakes

Validating Your Product Schema

When Product Schema Won't Help

Summary

Are Open Graph Tags Important for SEO and Social Sharing? I Ignored Them Until My Link CTR Started Dropping

How I Built a Privacy-First Browser Tool Suite to Fix My Own Freelance Workflow (No Backend, No Uploads, No Nonsense)

The Problem with "Free" Online Tools

The Architecture: Why Zero Backend?

How the Image Pipeline Actually Works

The Interesting Part: Building .ico Files from Scratch

What I Learned About AI-Assisted Development

SEO Structure: One Tool, One URL

What's Next

Try It

The `item` Field: Should the Last Crumb Have a URL?

Path 1: Safari — native OS decoder via `createImageBitmap`

Path 2: Chrome / Firefox — WebAssembly via `heic-to`

Paywalled Content: The `isAccessibleForFree` Pattern