DEV Community: Serhii Kalyna

Adding PDF support to a Rust image converter — what I learned about libvips and PDF rendering

Serhii Kalyna — Wed, 22 Apr 2026 15:40:54 +0000

Been building Convertify — a free image converter in Rust + Axum + libvips. This week I added PDF to JPG/PNG support. Thought I'd write up what actually happened because it was more interesting than expected.

The naive approach

My existing image pipeline is straightforward — VipsImage::new_from_file(path), some processing, image_write_to_file(out_path). Images just work. I assumed PDFs would be similar.

First attempt:

let image = VipsImage::new_from_file(&format!("{}[dpi={}]", file_path, dpi))?;

This actually works. libvips accepts PDF paths with a dpi parameter and returns a VipsImage. For a single-page PDF it's almost trivially simple.

Multi-page gets interesting

The problem is multi-page PDFs. You need to render each page separately and either return them as individual files or bundle them into a ZIP. My load_pdf function probes the file first to get the page count:

let probe = VipsImage::new_from_file(&file_path)?;
let quantity_pages = probe.get_n_pages();

Then for each page:

let image = VipsImage::new_from_file(&format!(
    "{}[dpi={},page={}]",
    file_path, dpi, num_page
))?;

The page parameter is zero-indexed. Simple enough. The output goes into individual files which then get zipped:

let mut zip = ZipWriter::new(file);
for page_file in &name_pages {
    zip.start_file(page_file, options)?;
    let data = std::fs::read(format!("./tmp/{page_file}"))?;
    zip.write_all(&data)?;
    std::fs::remove_file(format!("./tmp/{page_file}"))?;
    registry.lock().await.remove(page_file); // cleanup registry too
}
zip.finish()?;

The rendering engine question

libvips doesn't have its own PDF renderer — it delegates to either poppler or pdfium depending on how it was compiled. On most Linux distros you get poppler via the libvips-dev package. On a clean Ubuntu 24 EC2 instance this just worked, but I hit a subtle issue: some PDFs rendered correctly in Acrobat but had slightly different text positioning in my output. Turns out poppler's Splash rasterizer and pdfium's Skia backend produce noticeably different results on complex layouts.

If you're doing this in production and care about rendering quality, check what backend your libvips was compiled against:

vips --version
# also check what PDF loader is available:
vips -l | grep pdf

If pdfiumload is available alongside pdfload, you can use pdfium explicitly. The quality difference on text-heavy PDFs is visible — Skia's analytical coverage rasterizer produces cleaner edges than Splash.

DPI clamping

I added a DPI clamp on the server side — users can request any DPI but I limit it to 72–300:

let dpi = match params.get("dpi") {
    Some(value) => match value.parse::<i32>() {
        Ok(num) => num.clamp(72, 300),
        Err(_) => 150,
    },
    None => 150,
};

The reason: a 600 DPI A4 page produces a ~139 MB raw RGBA buffer. libvips streams this in tiles so it doesn't OOM, but it's still slow and the output file is huge. 300 DPI is the sweet spot for print-quality output — 2480×3508 pixels for A4, ~900 KB as JPG.
The cleanup bug I fixed this week
Completely unrelated to PDF but worth mentioning — noticed in the logs that cleanup_files was reporting it deleted hundreds of files when ./tmp was actually empty.
The bug: I was counting files to delete as to_delete.len() before actually attempting deletion. Page files from multi-page PDFs get removed immediately after zip creation, but their registry entries stuck around. So the cleaner found stale registry entries with no corresponding files on disk and counted them as successfully deleted.
Fix — count only files actually removed from disk, handle NotFound separately:

match tokio::fs::remove_file(&path).await {
    Ok(_) => {
        old_files_deleted += 1;
        reg.remove(&file_name);
    }
    Err(e) if e.kind() == std::io::ErrorKind::NotFound => {
        reg.remove(&file_name); // stale registry entry, skip count
    }
    Err(e) => {
        eprint!("Failed to delete {file_name}: {e}");
    }
}

What's next

PDF frontend is now live — DPI selection (72/150/300) and multi-page ZIP download are both shipped. You can try it at convertifyapp.net/pdf-to-png and convertifyapp.net/pdf-to-jpg.

Still considering whether to expose pdfium explicitly as a build option for better rendering quality, or just document the poppler default behavior. For now poppler works fine for the majority of PDFs people actually upload.

Building in public — week 5

Serhii Kalyna — Sat, 18 Apr 2026 13:37:36 +0000

Another week, mixed bag.

The main blocker is still HN karma. Sitting at 4, need 10+ for Show HN. Been leaving technical comments every day — libvips internals, AVIF encoder tradeoffs, Rust FFI stuff — but it just doesn't move. Not sure if it's timing, thread selection, or just how HN works for new accounts. Either way, Show HN moves to week 6.

What did happen: added Convertify to Wellfound and SourceForge this week. Small wins but both are DR80+ so it adds up over time. Also published a piece on TIFF in 2026 — researched the format properly and honestly it's kind of fascinating how dead it is on the web but still everywhere in print and professional workflows.

Also started PDF conversion. Using libvips pdfload instead of calling poppler directly — whole backend is already libvips so adding a separate dependency felt wrong. The tricky part is the probe load to get page count before processing, still working out the multi-page output strategy.

GSC is moving in the right direction — 52 pages indexed now, was 33 two weeks ago. Impressions are there, clicks still basically zero because everything sits around position 40. Need to crack top 20 on at least a few queries for that to change.

Week 5 vs week 4

Metric	Week 4	Week 5
Indexed pages	33	52
Reddit karma	60	75+
SO rep	21	87
Impressions	updating Sunday	—

TIFF in 2026: what I learned researching the format nobody uses on the web

Serhii Kalyna — Tue, 14 Apr 2026 15:18:18 +0000

I'm building a free image converter. One day I looked at my landing page for /tiff-to-webp and realized I had 4 sections of generic content — "TIFF is a lossless format, WebP is smaller, click convert." The kind of content that exists on 500 other sites.

So I spent a few hours actually researching TIFF. Here's what surprised me.

The file size math nobody explains

A 24-megapixel photo at 16-bit per channel is 144 MB. Not because TIFF is inefficient — because it stores every pixel at full depth:

Width × Height × Channels × Bytes per channel
6000 × 4000 × 3 × 2 = 144 MB

A 45MP Canon R5 TIFF hits ~260 MB. That's not a bug. That's the point. TIFF was designed for editing, not delivery.

Nine compression types — most people know two

Everyone says "TIFF is lossless." That's incomplete. TIFF supports:

Uncompressed — raw pixels, maximum compatibility
LZW — 1.5–2× compression, most common
ZIP/Deflate — slightly better than LZW for 16-bit images
JPEG-in-TIFF — lossy, 10–20× compression
CCITT Group 4 — 15–20× compression, black-and-white only

That last one is interesting. CCITT Group 4 is a lossless codec designed for bilevel (1-bit) images — fax machines used it for 30 years. A scanned business document compressed with Group 4 goes from 5 MB to ~250 KB. That's why multi-page TIFF became the standard for document archiving, legal scanning, and insurance workflows.

Zero browser support is by design

Chrome, Firefox, Edge — none of them render TIFF inline. Not a bug, not an oversight. TIFF was never meant for web delivery.

The Library of Congress lists TIFF as their preferred format for permanent digital preservation. They hold over 3.5 petabytes of TIFF files. The specification hasn't changed since June 3, 1992 — TIFF Revision 6.0. Thirty-plus years of stability is a feature when you're archiving cultural heritage.

The industries that actually use TIFF

When I dug deeper, TIFF turns out to be everywhere in specialized fields:

Professional photography — Lightroom exports 16-bit TIFF for Photoshop roundtrips. 65,536 tonal values per channel vs JPEG's 256.

Medical imaging — whole-slide pathology scanners produce BigTIFF files (64-bit offsets, no 4 GB limit). A tissue sample at 0.25 µm/pixel = ~80,000 × 60,000 pixels.

GIS / satellite imagery — GeoTIFF embeds coordinate systems and projections directly in the file. NASA Earthdata recommends Cloud Optimized GeoTIFF for all their data distribution.

Document scanning — multi-page TIFF with Group 4 compression is the standard for batch document processing. Every enterprise scanner defaults to it.

Archival — FADGI (Federal Agencies Digital Guidelines Initiative) requires TIFF for all government digitization projects.

The conversion numbers

Once I understood what TIFF actually is, the conversion ratios made sense:

Target	Reduction	Notes
WebP	~96%	36 MB → 1.6 MB at quality 80
JPG	~91%	82 MB → 7.6 MB at quality 85
PNG	~40–60%	Lossless, same quality
HEIC	~95–98%	96 MB → 2 MB, Apple only

PNG being "only" 40–60% smaller makes sense now — both are lossless, PNG just has better compression. HEIC being 98% smaller makes sense too — HEVC is an extremely efficient codec.

What this did for my content

Before research, my /tiff-to-webp page said: "TIFF is big, WebP is small, convert here."

After research, I could write about:

Why photographers export 16-bit TIFF from Lightroom before Photoshop retouching
Why NASA uses GeoTIFF for satellite imagery distribution
Why CCITT Group 4 still powers document scanning workflows
The difference between LZW and ZIP compression for 16-bit images

Same converter. Same tool. Completely different content that's actually useful to someone searching the topic.

That's the SEO approach I'm taking with Convertify — research every format deeply before writing a word. It takes longer. But generic content is invisible.

Week 5 of building in public. Previous posts in the series on my profile.

Building in public week 4: first organic clicks and what drove them

Serhii Kalyna — Sat, 11 Apr 2026 19:42:18 +0000

Week 4 of building my side project in public. Still early stage, but this week something shifted — first real organic clicks from Google.

What I worked on this week

Most of the week went into SEO fundamentals I'd been putting off:

Added Organization and WebSite schema to the whole site
Created Privacy Policy and Contact pages (E-E-A-T signals)
Fixed internal link ordering — replaced alphabetical with semantic scoring based on topical relevance
Expanded thin content pages with proper sections
Fixed HTTP→HTTPS redirect via Cloudflare

None of this is glamorous. But it's the kind of work that compounds.

What actually drove the clicks

Honest answer: I don't know yet. Too early to attribute. GSC data lags by a few days and the sample size is too small to draw conclusions.

What I can say is that impressions are trending up week over week, and the pages getting impressions are the ones where I added real content — not the thin placeholder pages.

What's next

More content on thin pages, waiting for Google to reindex the schema and E-E-A-T changes from this week, and continuing to build community presence slowly.

Building in public means sharing the slow weeks too. This was one of them — but the trend is pointing in the right direction.

Previous updates:

convertifyapp.net

Best Free Online Image Converters in 2026 — WebP, AVIF, HEIC and more

Serhii Kalyna — Tue, 07 Apr 2026 15:39:18 +0000

If you work with web images, you're converting between formats constantly. Here are 6 free tools worth knowing.

1. Convertify

Convertify supports WebP, HEIC, AVIF, PNG, JPG, TIFF and 20+ other formats. Built with Rust + libvips. Batch conversion up to 10 files, no signup, no watermarks, files deleted within 6 hours.

Pros: Fast, no account required, 20+ formats, quality control slider, batch conversion
Cons: 20MB per file limit, no editing features

2. Squoosh

Google's open-source tool. Runs entirely in the browser via WebAssembly. Excellent for fine-tuning compression — side-by-side preview and full control over encoding parameters.

Pros: In-browser, open source, excellent compression control, supports AVIF
Cons: Single file only, no batch conversion

3. Cloudinary

The industry standard for production image pipelines. Free tier gives you 25GB storage and on-the-fly format conversion via URL parameters.

Pros: API access, CDN delivery, automatic format negotiation
Cons: Requires account, overkill for simple conversions

4. ILoveIMG

Simple interface, handles batch WebP conversion well. Supports resize, compress, and crop alongside conversion.

Pros: Batch conversion, extra editing tools, no signup needed for basic use
Cons: Ads on the page, slower than dedicated converters

5. Convertio

Handles 300+ formats including WebP. Good for occasional use when you need a format the other tools don't support.

Pros: Huge format support, cloud storage integration
Cons: Free tier limited to 100MB, requires account for batch

6. EZGIF

Old-school UI but reliable. Good for WebP to GIF and animated WebP specifically.

Pros: Free, handles animated WebP, no account
Cons: Outdated interface, file size limits, ads

Bottom line

For most web developers: Squoosh for single files where you want compression control, Convertify for batch conversion across multiple formats without friction.

How I built a semantic scoring algorithm for internal links across >200 pages

Serhii Kalyna — Tue, 07 Apr 2026 11:01:50 +0000

Last week I wrote about why I added internal linking to my image converter. This is the technical follow-up: how I replaced alphabetical ordering with a semantic scoring algorithm.

The problem with alphabetical ordering

My RelatedConversions component was showing links in alphabetical order. For /heic-to-jpg, it would show avif-to-heic, avif-to-jpg, bmp-to-heic — technically related, but not semantically prioritized.

What I wanted: show conversions that share the most format overlap first, then factor in keyword similarity.

The scoring model: 70/30

A simple weighted formula:

format overlap — how many formats the two conversions share (weight: 0.7)
keyword similarity — do the slugs share meaningful terms (weight: 0.3)

function scoreRelation(current, candidate) {
  const [fromA, toA] = current.split('-to-');
  const [fromB, toB] = candidate.split('-to-');

  const formatsA = new Set([fromA, toA]);
  const formatsB = new Set([fromB, toB]);
  const shared = [...formatsA].filter(f => formatsB.has(f)).length;
  const formatScore = shared / Math.max(formatsA.size, formatsB.size);

  const wordsA = new Set(current.split('-'));
  const wordsB = new Set(candidate.split('-'));
  const sharedWords = [...wordsA].filter(w => wordsB.has(w) && w !== 'to').length;
  const keywordScore = sharedWords / Math.max(wordsA.size, wordsB.size);

  return (formatScore * 0.7) + (keywordScore * 0.3);
}

How it works in practice

For /heic-to-jpg:

jpg-to-heic → score 1.0 (both formats shared)
heic-to-png → score 0.7 (one shared format: heic)
webp-to-jpg → score 0.7 (one shared format: jpg)
avif-to-png → score 0.0 (no shared formats)

The component

export default function RelatedConversions({ from, to }) {
  const current = `${from}-to-${to}`;

  const ranked = SLUGS
    .filter(slug => slug !== current)
    .map(slug => ({ slug, score: scoreRelation(current, slug) }))
    .sort((a, b) => b.score - a.score)
    .slice(0, 8);

  return (
    <section>
      <h2>Related Conversions</h2>
      {ranked.map(({ slug }) => (
        <a key={slug} href={`/${slug}`}>
          {slug.replace('-to-', ' to ').toUpperCase()}
        </a>
      ))}
    </section>
  );
}

What's next

Planning to weight by GSC impression data — pages that already rank should get higher weight in related links. That closes the feedback loop: organic traffic signals inform which related conversions to surface.

Building in public at convertifyapp.net.

Is HEIC Patent Risk Real for Small Web Services?

Serhii Kalyna — Mon, 06 Apr 2026 12:51:35 +0000

Apple uses HEIC as the default iPhone photo format — which means almost every image your users upload from iOS is potentially HEIC. But HEIC is built on HEVC, which is encumbered by a messy patent pool (MPEG LA + HEVC Advance).

The question

If you're running a small, free image converter that processes HEIC files server-side, are you actually exposed to legal risk?

Here's what I found after researching this for Convertify:

Patent holders typically target device manufacturers and encoders, not web services
There's no known case of a small web service being sued for HEIC processing
Using libheif (open source) doesn't grant a patent license, but practically, enforcement at this level hasn't happened
The real risk threshold seems to be commercial scale — think millions of users or hardware bundling

My conclusion

Theoretical risk exists, but practical risk for indie/small services is low.

Has anyone dealt with this, consulted a lawyer, or found solid resources on this topic? Would love to hear from others who've thought it through.

From 0 to 30 indexed pages in 3 weeks — what actually moved the needle

Serhii Kalyna — Sat, 04 Apr 2026 10:45:14 +0000

From 0 to 30 indexed pages in 3 weeks — what actually moved the needle

I'm building Convertify — a free image converter that supports 20+ formats with no signup, no limits, and no file tracking. Solo project, built with Rust + libvips on the backend and Next.js on the frontend.

Three weeks ago Google had indexed exactly 0 pages. Here's what I changed and what actually worked.

The starting point: a Vite SPA that Google couldn't read

The original version was a classic React SPA bundled with Vite. Fast to build, great DX — and completely invisible to Google. Googlebot would hit the page, get an empty HTML shell, and move on. No content to index.

The fix was straightforward in theory: migrate to Next.js App Router with SSG. In practice it took a few days, but the result was 186 fully rendered static pages generated at build time — one for every format combination the tool supports.

That alone got me from 0 to around 16 indexed pages in the first two weeks. But then growth stalled.

What actually moved the needle in week 3

1. Schema markup on every page

I added FAQPage + HowTo JSON-LD schema to every converter page. Not just one or two — all 186.

The FAQPage schema answers the questions people actually ask: "What is HEIC?", "Will my photos lose quality?", "How long does conversion take?". The HowTo schema describes the conversion steps in structured format Google can parse.

Result: impressions jumped, and GSC started showing the pages in rich result eligibility.

2. Content expansion from ~500 to 5000–7000 characters

This was the most time-consuming part. Each landing page went from a thin paragraph to a full article: format comparison tables, browser support matrices, compression benchmarks, use case explanations, and a 6–8 question FAQ.

Thin content is invisible. Google doesn't rank pages that don't say anything useful. The pages that got indexed first were the ones with the most content.

3. Internal linking cluster (RelatedConversions component)

I built a RelatedConversions component that appears on every converter page and links to 8–10 related conversions. For example, /heic-to-jpg links to /heic-to-png, /jpg-to-webp, /png-to-jpg, and so on.

This does two things: it passes PageRank between pages in the same cluster, and it gives Googlebot a clear crawl path through the entire site. Before this, pages were islands. After this, they're a connected graph.

4. About page with E-E-A-T signals

Google's helpful content guidelines care about who is writing the content. I added an About page with Person schema (name, job title, links to dev.to articles) and WebSite schema with a sitelinks search box.

It's not a magic ranking factor, but it signals to Google that there's a real person behind the site — not a content farm.

Results after 3 weeks

Metric	Week 0	Week 3
Indexed pages	0	30
GSC impressions (7d)	0	160
Unique search queries	0	45
PageSpeed (mobile)	—	100/100

30 indexed out of 186 total means Google is still crawling. The indexing curve is moving in the right direction — pages that got schema + expanded content are getting indexed first.

Positions are averaging around 55, which means page 5–6. Clicks come when you hit the top 10. That's the next phase.

What didn't work (or not yet)

Backlinks — I have ~47 linking domains in Ahrefs, but most are toxic spam (pharma sites, fake testimonial networks). Real quality backlinks: about 3–5. This is the biggest gap right now.

Reddit — posted in r/webdev and r/juststart, both got auto-removed. New accounts trigger spam filters regardless of content quality. Building karma through comments first before trying posts again.

Impressions without clicks — 160 impressions at position 55 means the pages are being seen but aren't competitive yet. More content depth and backlinks should push positions into the top 20, where CTR starts to matter.

What's next

Push /heic-to-jpg and /avif-to-jpg to 1000+ words with full schema (these are the highest-volume queries)
Get HN karma to 10+ and do a Show HN post
Outreach to "best free image converters 2026" listicle authors for genuine backlinks
Track whether internal linking cluster improves crawl coverage in GSC

Stack

Backend: Rust + Axum + libvips (image processing)
Frontend: Next.js 16 App Router, SSG
Database: PostgreSQL (landing page content)
Infrastructure: VPS + Caddy + PM2

The site: convertifyapp.net — no signup, no limits, 20+ formats.

AVIF in 2026: why it's the best format for web images

Serhii Kalyna — Thu, 02 Apr 2026 16:30:31 +0000

AVIF has been available since 2020, but it's only in 2026 that it became the obvious default choice for web images. Browser support crossed 94.9%, Google officially recommends it in PageSpeed Insights, and the compression advantages over JPG are too large to ignore. Here's what you need to know.

What is AVIF?

AVIF (AV1 Image File Format) is an image format developed by the Alliance for Open Media — a consortium that includes Google, Apple, Mozilla, Microsoft, and Netflix. It uses the AV1 video codec to compress images, which is why it achieves compression rates that traditional image codecs like JPG can't match.

AV1 was designed for video — it's optimized for the kind of complex, natural content that appears in photos and real-world scenes. When you use it for a single image frame instead of a video stream, you get dramatically better compression than JPG's DCT-based algorithm, which dates back to 1992.

The compression numbers

At equivalent visual quality (measured by SSIM/DSSIM), AVIF consistently beats JPG by 40–60%:

Format	File size vs JPG	Browser support
JPG	Baseline	All browsers & apps
WebP	~30% smaller	95.67%
AVIF	~50% smaller	94.9%
JPEG XL	~45% smaller	14.7% (Safari only)

A real example from my own testing with libvips:

JPEG (q80): 540 KB
WebP: 350 KB (−35%)
AVIF: 210 KB (−61%)

That's not a cherry-picked example — Netflix's internal benchmarks across a diverse image dataset showed AVIF achieving ~50% better compression than JPG on average.

Why AVIF wins over WebP in 2026

WebP was Google's previous recommendation and it's still a solid format. But AVIF has caught up in browser support (94.9% vs 95.67%) while delivering meaningfully better compression.

The gap matters at scale. If you have 1,000 product images averaging 400 KB as JPG:

WebP: ~270 KB each → 270 MB total
AVIF: ~200 KB each → 200 MB total

That's 70 MB less bandwidth per 1,000 images served. For high-traffic sites, this compounds into significant CDN cost savings and faster page loads.

Core Web Vitals impact

Largest Contentful Paint (LCP) measures how quickly the main image on a page loads. It's a Google ranking signal and one of the Core Web Vitals metrics.

Large images are the most common cause of poor LCP scores. Switching from JPG to AVIF typically reduces image payload by 40–60%, directly improving LCP. Google's PageSpeed Insights will flag JPG images as a performance opportunity and explicitly recommend AVIF as the preferred replacement.

For e-commerce sites where product images are the LCP element, converting to AVIF is the highest-impact single change for page performance.

Browser support in 2026

AVIF achieved Baseline status in 2024:

Chrome 85+ (2020)
Firefox 93+ (2021)
Safari 16+ (2022)
Edge 121+ (2024)

The ~5% without support is primarily legacy mobile browsers and Internet Explorer. For most sites, you can serve AVIF as the primary format with a JPG fallback using the HTML <picture> element:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="description">
</picture>

Browsers download only the first format they support.

The encoding speed problem

AVIF's biggest practical limitation is slow encoding. While JPG encodes in ~2ms and WebP in ~168ms, AVIF takes 1–2 seconds per image with the libaom reference encoder.

This makes real-time AVIF encoding impractical for user-uploaded content without a job queue. For static assets (product photos, blog images, landing page assets), encode offline during your build process and serve the pre-encoded AVIF files.

Alternative encoders help:

rav1e — faster than libaom, slightly larger files
SVT-AV1 — good balance of speed and compression

In my Rust + libvips backend for Convertify, I use libvips's built-in AVIF support which wraps libaom. For batch conversion of user files, the encoding time is acceptable. For real-time conversion of large files, it's a constraint worth planning around.

AVIF transparency and animation

Unlike JPG, AVIF supports full alpha channel transparency. This makes it a potential replacement for PNG in web contexts — smaller files with the same transparency support.

AVIF also supports animation, making it an alternative to GIF. Animated AVIF files are significantly smaller than GIF while supporting a full color range (GIF is limited to 256 colors).

What about JPEG XL?

JPEG XL (JXL) is technically superior to AVIF in some dimensions:

Better compression at high quality settings (~20% smaller than AVIF)
Progressive decoding (shows usable image with 1% of data loaded)
Lossless JPEG transcoding (20% smaller, byte-perfect reconstruction)

The problem is browser support: 14.7% as of early 2026, limited to Safari 17+.

The big news: Chrome Canary 145 shipped a Rust-based JXL decoder in late 2025, reversing Google's 2022 decision to remove JXL support. Realistic stable Chrome support: H2 2026.

My recommendation: Use AVIF now. Watch JXL for H2 2026 when Chrome stable support arrives. Don't wait.

Practical implementation

For static sites: Convert during build. Store both AVIF and JPG. Use <picture> for fallback.

For CDNs: Cloudflare, Cloudinary, and Imgix serve AVIF automatically via Accept header negotiation. Upload once, let the CDN handle format selection.

For Next.js: The <Image> component serves AVIF automatically for supported browsers since Next.js 13.

For WordPress: ShortPixel, Imagify, and WebP Express all support AVIF conversion.

For manual conversion: Tools like Convertify handle batch AVIF conversion without requiring local tooling.

Summary

AVIF is the right default for web images in 2026:

✅ 94.9% browser support — effectively universal with JPG fallback
✅ ~50% smaller than JPG at the same quality
✅ Recommended by Google PageSpeed Insights
✅ Transparency and animation support
⚠️ Slow encoding — plan around it for real-time use cases
⚠️ Limited app support outside browsers

The implementation is straightforward. The performance gains are significant. There's no good reason to keep shipping JPG for web images in 2026.

Why I added internal linking to my image converter (and what changed in Google)

Serhii Kalyna — Tue, 31 Mar 2026 17:11:48 +0000

I've been building Convertify — a free image converter powered by Rust + libvips. Two weeks in, Google had indexed 18 of my 186 static pages. The numbers were moving, but slowly.
Then I read a recommendation that changed my approach: internal linking is 80% of cluster SEO.

The problem

My converter pages existed in isolation. /heic-to-jpg had no idea /heic-to-png existed. Google couldn't see a cluster — just a collection of unrelated tools.

What I built

A RelatedConversions component that generates contextual links on every page:

const RELATED: Record<string, string[]> = {
  heic: ["jpg", "png", "webp", "avif"],
  avif: ["jpg", "png", "webp", "heic"],
  // ...
};

export default function RelatedConversions({ from, to }) {
  // generates links like "HEIC to PNG", "WEBP to JPG" etc.
  // deduplicates, shows related formats from both source and target
}

On the homepage — "Popular Conversions". On converter pages — "Related Conversions". Every page now links to 6-8 related pages.

The immediate result

Deployed on day 15. The same day I submitted the key pages for re-indexing in Search Console.
Within 24 hours Google crawled the updated pages. The internal links give Googlebot a clear path through the entire site — it no longer needs to discover pages through the sitemap alone.

What's next

Still too early to see ranking changes — SEO takes weeks. But the site now looks like a cluster to Google, not a collection of isolated tools. That's the foundation for ranking multiple pages simultaneously for the same search query.

Stats so far (week 3, day 2):

18 pages indexed (up from 2 three weeks ago)

Building in public. Follow along if you're curious how Rust + Next.js SSG performs for SEO.

Building Convertify in public. Previous posts:

AVIF converter: why I built one and what I learned

Serhii Kalyna — Mon, 23 Mar 2026 16:04:29 +0000

Large images slow down websites, frustrate users, and hurt SEO. Modern formats like AVIF promise smaller sizes with better quality, but the ecosystem is still young. I decided to explore AVIF and build my own converter to see what works in practice.

Why AVIF

AVIF images can be 50–70% smaller than JPEG or PNG at similar or better visual quality. This means faster loading times, lower bandwidth, and improved PageSpeed scores. Yet, support for AVIF in editing tools and converters is still limited, which makes it hard for developers and content creators.

Why I built my own converter

Existing tools are either slow, require file uploads (privacy concerns), or are paid. I wanted a converter that is fast, privacy-first, and free. That led me to create Convertify.

Tech stack

Rust for performance-critical processing
libvips as a high-speed image processing backend
Next.js SSG for static landing pages and SEO

Challenges

AVIF encoding is slower than JPEG/PNG
Browser compatibility is still patchy
UX: making drag & drop intuitive without blocking the main thread

Results

Conversion speed improved significantly with Rust + libvips
PageSpeed scores for test pages increased
Early users appreciated privacy-first, instant conversion

Conclusion

AVIF adoption will grow as tools improve. Building your own converter is a great way to learn about modern image formats and get early traction. Check out a quick AVIF-to-JPG demo Convertifyapp.

How I fixed Google ignoring 160 pages: migrating from Vite SPA to Next.js SSG

Serhii Kalyna — Sat, 21 Mar 2026 17:59:51 +0000

How I fixed Google ignoring 160 pages: migrating from Vite SPA to Next.js SSG

I've been building Convertify — a free image converter
that supports HEIC, WebP, AVIF, PNG, JPG and 20+ formats.

The problem: after weeks of work, Google had indexed exactly 2 pages out of 160+.

Why Google ignored my pages

My app was a Vite React SPA. Every route looked like this in HTML:

<!DOCTYPE html>
<html>
  <head>
    <title>Convertify</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/assets/index.js"></script>
  </body>
</html>

Google crawls without executing JavaScript. So every single page —
/heic-to-jpg, /webp-to-png, /avif-to-jpg — returned identical empty HTML.
Google saw them all as duplicates and indexed only the homepage.

The fix: Next.js App Router + generateStaticParams

I migrated to Next.js and used generateStaticParams() to pre-render
all format pairs at build time:

export async function generateStaticParams() {
  const formats = ['heic', 'jpg', 'jpeg', 'png', 'webp', 'avif', 'gif', 'bmp', 'tiff']
  const params = []
  for (const from of formats) {
    for (const to of formats) {
      if (from !== to) params.push({ slug: `${from}-to-${to}` })
    }
  }
  return params
}

Result: 186 static HTML pages generated at build time.

Server components for SEO content

The key insight: not everything needs to be a client component.

I split the page into two parts:

Client (interactive): DropZone, Settings, ConvertButton, FilesViewer
Server (static HTML): FAQ, HowToConvert, SupportedFormats, Header, Footer

For server components I replaced MUI Accordion with native HTML <details>/<summary>:

// No 'use client', no JavaScript, pure HTML
const FAQ = ({ from, to }: { from?: string; to?: string }) => {
  return (
    <dl>
      {faqs.map((faq, i) => (
        <details key={i}>
          <summary>{faq.question}</summary>
          <dd>{faq.answer}</dd>
        </details>
      ))}
    </dl>
  )
}

Google gets full FAQ content without running any JavaScript.

Dynamic metadata per page

Instead of react-helmet-async, Next.js handles metadata server-side:

export async function generateMetadata({ params }) {
  const [from, to] = params.slug.split('-to-')
  return {
    title: `Convert ${from.toUpperCase()} to ${to.toUpperCase()} Online Free — Convertify`,
    description: `Free online ${from.toUpperCase()} to ${to.toUpperCase()} converter.`,
    alternates: { canonical: `https://convertifyapp.net/${params.slug}` },
  }
}

Every page now has unique title, description and canonical tag in the HTML
— no JavaScript required.

Results

Before: 2 indexed pages
After: 186 static pages pre-rendered
PageSpeed Desktop: 100/100 Performance, 100/100 SEO
PageSpeed Mobile: 83/100 Performance, 100/100 SEO

The mobile performance hit comes from MUI (emotion) on the client side.
Working on reducing that next.

Lessons learned

SPAs are SEO poison for content pages. Use SSG or SSR.
Split server/client components — only interactive parts need JavaScript.
Native HTML elements (<details>, <summary>) work great for accordions and are fully server-renderable.
generateStaticParams is incredibly powerful for programmatic SEO pages.

If you're building a tool with many landing pages — don't make the same
mistake I did. Start with Next.js from day one.

Check out Convertify if you need to convert
HEIC, WebP, AVIF or any other image format — free, no signup, no limits.