DEV Community: Serhii Kalyna

AVIF encoding speed — the numbers nobody talks about

Serhii Kalyna — Thu, 14 May 2026 16:16:27 +0000

Everyone talks about how small AVIF files are.

Almost nobody talks about what it costs to generate them in production.

I run a free image converter built on Rust + libvips. After processing thousands of conversions, here are the numbers that changed how I think about format choice.

The compression story you already know

AVIF beats WebP on file size. For photos and gradients:

AVIF saves ~50% vs JPEG (median across 600 photos)
WebP saves ~31% vs JPEG
At the same DSSIM score, AVIF produces files ~50% smaller than WebP

Real and impressive. But that's only half the equation.

The encoding cost nobody talks about

Here's what actually happens when you encode with libaom (the default AVIF encoder):

Format	Encoding time (1080p)	Peak CPU	Peak RAM
WebP	~90ms	~20%	~200MB
AVIF (libaom, default settings)	1–4 seconds	~400% (4 cores)	~2.5GB
AVIF (maximum quality)	up to 48 seconds	-	-

In my tests, AVIF encoding with libaom was up to 47× slower than WebP at comparable quality settings. Peak memory usage during a single 4000px AVIF conversion reached ~2.5GB in Sharp/libvips using libaom. WebP used ~200MB for the same image.

The memory usage surprised me most. For a service handling concurrent batch uploads, that's not a benchmark number - it's a capacity planning problem.

AVIF optimizes bandwidth. WebP optimizes compute.

The `effort` parameter an oversimplification

If you use Sharp, you've probably assumed: higher effort = smaller files.

In practice, it's not that simple.

quality is the primary driver of file size. effort controls how much time the encoder spends searching for better compression decisions. Depending on the image, higher effort can slightly reduce or even increase output size. The effect is unpredictable and usually marginal.

This is documented behavior in Sharp's issue tracker (#3418): at fixed quality, increasing effort sometimes produces larger files.

Practical starting point for AVIF in Sharp:

sharp(input).avif({ quality: 72, effort: 5 }).toBuffer()

effort: 5-6 hits a reasonable balance. Going to effort: 9 adds seconds of encoding for marginal and unpredictable gains.

When to use which format

Scenario	Best format
User uploads processed on-the-fly	WebP
Static assets, pre-generated at build	AVIF
Real-time transforms	WebP
Maximum compression for photos	AVIF
Low-memory servers	WebP
Screenshots, UI, flat graphics	WebP
Photography, gradients, textures	AVIF

The rule I follow: AVIF for static, WebP for dynamic.

A 4-second encoding time is fine in a CI pipeline. It's not fine when a user is waiting for their converted file.

What this looks like in a converter pipeline

In my converter pipeline, the challenge with AVIF isn't throughput it's memory spikes under concurrent load. If multiple users upload large images simultaneously, AVIF jobs can spike memory hard across all cores.

Current approach:

Concurrency limits on AVIF jobs
Default effort: 4 for interactive conversions fast enough for real-time use
SVT-AV1 encoder is worth watching: roughly 2× faster than libaom, 5× faster than rav1e at comparable quality

Browser support

Effectively solved:

WebP: ~95.6% global support (Safari 14+, all modern browsers)
AVIF: ~94.3% global support (Safari 16.4+, Chrome 85+, Firefox 93+)

The standard fallback pattern still makes sense:

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

The actual takeaway

"Better compression" and "better for your use case" aren't the same thing.

AVIF is technically superior for compression. But if you're encoding on-the-fly, the encoding overhead is a real operational cost not a benchmark footnote.

WebP is fast, lightweight, and produces files dramatically smaller than JPEG. It's not a consolation prize.

The best setup: pre-generate AVIF for static assets, encode WebP dynamically, serve both via <picture> or CDN content negotiation.

Building Convertify a free image converter powered by Rust + libvips. Week 9 of building in public.

Sources: Sharp GitHub issues #2597, #3418 · libheif AVIF Encoder Benchmark · SpeedVitals WebP vs AVIF · W3Techs image format statistics (May 2026) · Can I Use

Building in public, week 8: impressions exploded 71% and I think I know why

Serhii Kalyna — Sun, 10 May 2026 12:21:24 +0000

So this week something actually happened.

I've been building Convertify - a free image converter (Rust + libvips backend, Next.js frontend) - for about 2 months now. Writing content, fixing schema, submitting to directories, watching Google mostly ignore me.

This week the numbers moved.

The numbers

Google Search Console, 3-month view:

Impressions: 271 -> 463 (+71%)
Indexed pages: 59 -> 72 (+13)
External links: 40 -> 65 (+25)
Average position: 40.8 -> 43.8 (worse, but I'll explain)

That impressions jump is the biggest I've ever had.

What I think caused it

I don't think it was one thing.

Week 7 I updated 19 pages - added content sections, cross-links, fixed a schema bug where 189 FAQ entries were missing from JSON-LD.

Week 8 I did Semrush-driven fixes - put target keywords in H1s and titles, simplified sentences for readability, added semantic terms that competitors use but I wasn't. Also brought 16 pages up to 8+ FAQ each.

My theory is Google re-crawled the batch of updated pages and suddenly saw: "oh wait, these pages actually have real content now, not just a converter widget and two paragraphs."

The position thing

Average position went from 40.8 to 43.8 which looks bad. But 13 new pages got indexed this week, and they all start at positions 50-80. That drags the average down even though the older pages are actually climbing.

One page - jpg-to-webp - is at position 5.8 with 39 impressions. Position 5.8! That's basically page one. Zero clicks though. Working on the title/description to fix CTR.

What I built this week

Shipped batch image-to-PDF. You drop up to 10 images, pick page size (A4/Letter) and orientation, get one combined PDF. Built the PDF from raw bytes in Rust — no PDF library, just manually constructing xref tables and DCTDecode streams. Was it overkill? Probably. Was it fun? Absolutely.

Also refactored the entire Rust backend - split a 1200-line main.rs into proper modules (db, errors, image, notification, path, pdf). Should've done this weeks ago.

Backlinks update

Got on StackShare (DR ~89) and submitted to Capterra (DR ~91, pending review). Capterra was interesting - one submission potentially gets you on Capterra + Software Advice + GetApp, all three owned by Gartner.

Tried a few other directories from my backlink plan. Turns out FeedMyApp is dead (domain expired in 2022), Go2Web20 is dead, VentureBeat Profiles doesn't exist as a free thing anymore, and BetaList wants $39 minimum. So that saved me some future time at least.

Organic search is now #1 traffic source

This is the thing I'm most excited about. search.google.com has been the top traffic source for two weeks straight now. It's small numbers but the trend is clear.

The new /images-to-pdf page immediately became the #2 most viewed page on the site. Google picked it up fast.

What's next (week 9)

Biggest gap right now: 24 out of 64 pages have no cross-links in their body text. Plan is to add 2-3 natural cross-links per page across all 24 this week.

Also rewriting titles and meta descriptions for pages that are ranking but not getting clicks.

If you want to try it: convertifyapp.net. 40+ format pairs, batch conversion, image-to-PDF. Free, no signup.

Previous weeks: week 7 | week 6

From 0 to 72 indexed pages in 2 months: what Google actually does with new sites

Serhii Kalyna — Fri, 08 May 2026 19:57:15 +0000

I've been building Convertify — a free image converter in Rust + Next.js — for about 2 months. Here's where I am in GSC right now:

72 indexed pages
Average position: 40.8
Impressions: ~90/day
Clicks: basically 1

Not glamorous. But I spent time researching what's actually happening under the hood, and it changed how I think about the whole thing.

The "Google Sandbox" thing

Everyone talks about it. New site, no traffic, must be the sandbox right?

John Mueller said it directly in 2019: "There is no sandbox." Google doesn't penalize new sites — it just hasn't collected enough trust signals yet. There's a difference.

What actually happens is closer to this timeline:

Week 1: pages get crawled and indexed
Weeks 2–6: Google tests your pages on low-volume queries
Month 2–3: first stable positions for long-tail keywords
Month 4–6: rankings start to stabilize
Month 6–12: meaningful traffic growth

I'm at month 2. Right on schedule for "still basically nothing."

What actually moved the needle for me

A few things that made a real difference early:

Static site generation. I migrated from a Vite React SPA to Next.js SSG specifically because Google wasn't indexing my pages. Dynamic JS rendering was killing crawlability. After the migration: 186 static pages, all indexable. Impressions jumped within 2 weeks.

Internal linking. Added RelatedConversions component — every page links to 10-14 related conversion pages. Before this, new pages were getting zero impressions. After: slow but steady crawl pickup.

FAQ schema. Every landing page has FAQPage JSON-LD with 8-10 real questions. Not for rich snippets (those don't show for this type) — for entity clarity and content depth signals.

Content depth over breadth. Instead of 5 shallow pages, I focused on making each conversion page actually useful — real technical comparisons, format history, use cases. Some pages now have 10+ sections.

What didn't work (yet)

Backlinks. I spent time on directory submissions, Reddit posts, forum comments. Honest assessment: the directories that matter have 2-4 month queues. The "best image converter" articles are written by competitors. Forum comments get removed.

The only backlink strategy that feels real right now is writing content that people actually want to link to. Which is why I'm writing this.

CTR is also rough — 1 click total at position 40. That's expected. You can't get clicks from page 4. The only fix is ranking higher, which takes time.

What I'm watching now

GSC shows a spike in impressions at end of April — new pages entering the index. Then a drop. Mueller warned about this: "a site may get a spike, then return to normal — that's when you need patience."

I'm in the patience phase.

Month 4-6 is supposedly when things stabilize. I'll report back.

The honest summary

If you launched a site recently and have basically no traffic — you're probably fine. Google isn't punishing you. It's just waiting to see if you're serious.

The things that seem to matter most in the first 3 months: static rendering, internal linking, content depth, and schema markup. Not backlinks. Not social media. Just making the site technically solid and giving Google something worth indexing.

We'll see if that holds at month 6.

Building Convertify in public — free image converter, Rust + libvips backend, Next.js SSG. Week 8 of the build.

Building in public, week 7: 19 pages, 189 missing FAQ entries, and organic search finally showing up

Serhii Kalyna — Sun, 03 May 2026 17:28:38 +0000

TL;DR: I shipped image → PDF conversion but spent most of the week on SEO content instead of the planned batch UI and landing page. The numbers say that was the right call. Organic search became the #1 traffic source for the first time.

Convertify is a free image converter I'm building solo: Rust + Axum + libvips on the backend, Next.js 16.2 SSG on the frontend, PostgreSQL for landing page content. Every week I publish what worked, what didn't, and the real situation behind it.

Here's week 7.

What actually happened vs. the plan

The plan was clear: ship image → PDF with full batch UI (page size options, orientation picker) plus a dedicated /images-to-pdf landing page, and catch up on community engagement.

What actually happened: image → PDF conversion works — you can convert JPG, PNG, WebP to PDF right now. But the batch UI (combining multiple images into one PDF with layout controls) and the dedicated landing page didn't get built. Instead I went deep on content.

What I did instead of the planned batch work: mass content expansion. Created 9 new landing pages, updated 5 existing ones to full content, improved 5 more that were lagging behind, and found a critical bug in my structured data that had been silently hurting SEO for weeks.

The reason was simple. I opened the database, looked at the gaps, and realized that getting 19 pages from thin/empty to complete would compound for months. The batch UI and /images-to-pdf page would polish one feature. Content would give me 19 new entry points into Google. I picked the compounding bet.

The schema_faq bug — 189 missing questions

This was the real find of the week.

I have faq fields on every landing page (the visible FAQ accordion) and schema_faq fields (the JSON-LD FAQPage markup that Google reads for rich results). They're supposed to match. They didn't.

When I checked: 55 out of 62 pages had fewer questions in schema_faq than in faq. That's 189 questions Google couldn't see in structured data — almost a third of my entire FAQ content was invisible to rich results.

The cause was boring: schema_faq was written manually when I first created each page, and never updated when I added more FAQ entries later. Classic data sync bug.

The fix had two parts. First, a SQL migration that synced all 56 pages. Second, a frontend fix in FAQ.tsx — I removed the landing?.schema_faq ?? fallback so the component now always generates schema from faqItems directly. The desync can't happen again.

This is one of those bugs that costs you nothing visibly but bleeds SEO silently. You don't notice it until you audit.

Content expansion: three clusters

TIFF cluster — 5 new pages. JPG→TIFF, PNG→TIFF, PDF→TIFF, HEIF→TIFF, AVIF→TIFF. These target print/archival workflows — people who need lossless containers for prepress, medical imaging, GIS. Low volume keywords but almost zero competition.

GIF cluster — 4 new pages. WebP→GIF, AVIF→GIF, HEIF→GIF, HEIC→GIF. The use case is mostly "I have a modern format and need an animated GIF for legacy platforms." Slack, older email clients, forums that only accept GIF — it's still a thing in 2026.

HEIF pairs — 5 existing pages rewritten. HEIF→JPG, HEIF→PNG, HEIF→WebP, HEIF→AVIF, HEIF→HEIC. These existed but had minimal content. Now each has 7+ sections explaining the difference between HEIF (the container) and HEIC (HEIF + HEVC codec), with comparison tables and full FAQ.

Partial pages filled — 5 more. PNG→HEIC, HEIC→WebP, GIF→JPG, GIF→BMP, GIF→HEIC all got expanded to full content.

Every page also got cross-links embedded in the content body — teal-styled <a> tags pointing to related conversions. The ContentSections.tsx component now supports dangerouslySetInnerHTML for these, plus paragraph splitting on \n\n so content doesn't render as walls of text.

Frontend work: RelatedConversions upgrade

The internal linking component got a proper overhaul. Before, it was semi-random. Now it uses a VALID_SLUGS set (no more 404 links), reverse-route boosting (if you're on A→B, the B→A page ranks high), family overlap scoring, and a HEIC/HEIF sibling bonus. Max 14 links per page, all validated against actual database slugs.

Small thing, but internal linking is one of those levers where the improvement compounds across every page simultaneously.

The numbers

Google Search Console is moving in the right direction. Indexed pages went from 52 to 59. Impressions had the biggest single-week jump since launch. Average position dropped below 41 for the first time — slow grind but it's grinding the right way. GSC also unfroze after the data lag from week 6, so the dashboard is fresh again.

Clicks are still minimal. The math is straightforward: at position ~40, CTR is basically zero. I need to crack top 20 on at least a few queries before clicks become meaningful. That's not a content problem — that's a time-and-authority problem.

Google Analytics showed the signal I've been waiting for: search.google.com became the #1 traffic source this week — beating Reddit, Threads, and everything else. First time organic search has been on top. Active users grew by 40% week over week, and new users by nearly 70%.

Semrush Site Audit came back clean: 98% health score, zero errors. No broken links, no redirect chains, no orphan pages. The remaining warnings are minor — some pages flagged for low text-to-HTML ratio (expected with Next.js SSG where the JS bundle is heavy relative to static content), and two pages with low word count that I'll bulk up in the next round. The site also passed all Core Web Vitals checks, and the crawl depth stays within 3 clicks for nearly everything. For a solo project with 60+ landing pages, I'm pretty happy with that baseline.

What I'm noticing

1. Content × schema = compound effect. Every page I fix works 24/7 for months. That's fundamentally different from a Reddit post that peaks in 48 hours. The schema_faq fix alone means Google now sees 189 more questions across the site. That's not a one-time bump — it's a permanent improvement to how the site appears in search.

2. Organic traffic is real now. It's still small. But seven weeks ago it was literally zero. The trend line matters more than the absolute number. And when you see Google outpace your referral channels for the first time — that's a signal.

3. Community engagement suffered again. Two weeks in a row with minimal Reddit/dev.to activity. Karma flatlined, HN karma still stuck. This is becoming a pattern I need to break in week 8.

Honest moment

I planned to ship a polished feature with batch UI and a landing page. I shipped the core conversion and then pivoted to content instead. It feels less exciting to write about — "I updated 19 database rows" doesn't have the same energy as "I built a multi-image PDF composer."

But looking at the analytics, this was probably the highest-ROI week so far. Every page I created or fixed is now a permanent surface area for organic discovery. The schema bug fix alone was worth the entire week.

Sometimes the boring work is the important work.

Week 8 plan

Primary: finish the image → PDF experience — batch upload (multiple images into one PDF), page size/orientation options, and the /images-to-pdf landing page. The conversion works, now it needs the polish.

Secondary: re-engage community channels. Daily Reddit/dev.to comments, one new article, one Reddit post. Two weeks of silence is too long.

Not doing: new SEO clusters, big redesigns, or chasing new platforms.

Convertify is a free, ad-free image converter. convertifyapp.net — weekly updates every Sunday.

Building in public, week 6: PDF support is live — but I had to sacrifice content for it

Serhii Kalyna — Sun, 26 Apr 2026 17:53:18 +0000

TL;DR: I shipped PDF → image conversion this week. The cost? Three days redesigning the converter UI, and falling behind on community content. Solo dev tradeoffs are real.

Convertify is a free image converter I'm building solo: Rust + Axum + libvips on the backend, Next.js SSG on the frontend, PostgreSQL for landing page content. Every week I publish what worked, what didn't, and the numbers behind it.

Here's week 6.

What shipped: PDF support (Wednesday)

The big one. Convertify now converts PDFs to images — JPG, PNG, WebP, and so on. Multi-page PDFs are bundled into a ZIP with one image per page.

What's not shipped yet: the reverse direction (image → PDF). That's the headline feature for week 7.

How I integrated PDF in libvips

libvips itself doesn't speak PDF natively — you need a backend. I'm using a libvips extension that wraps the heavy lifting (I'll dig into the exact crate / build flag in a follow-up post once I'm sure I'm describing it correctly — there are a few moving parts and I don't want to misinform).

The flow is straightforward:

Upload PDF → temp file
Page count via the PDF backend
Loop through pages, render each to a raster at the requested format/quality
If single page → return the image directly
If multi-page → stream a ZIP containing all rendered pages

The ZIP path was the part I spent the most time on. Stream-zipping in Rust without buffering everything in memory took some plumbing — but it pays off the first time someone uploads a 50-page PDF and the server doesn't OOM.

Landing pages

PDF launched with the full set of landing pages already drafted: /pdf-to-jpg, /pdf-to-png, /pdf-to-webp, etc. They're in the same SSG pipeline as the rest of the site (Postgres → static build → Caddy).

The interesting signal: the PDF to PNG page is already the #2 most-visited page on the site after the homepage, three days after launch. No marketing, no posts about it yet. Just organic discovery.

That's the kind of thing that makes you want to ship faster.

What didn't ship: content + image→PDF

Thursday, Friday, and Saturday I spent redesigning the converter UI itself — the format picker, the upload area, the buttons component system (migrating off MUI to a custom CSS-modules-based system to drop bundle size).

That redesign was overdue. But it cost me three days of community content work I'd planned: replies on Reddit, comments on dev.to articles in my space, follow-ups in subreddits I've been growing in. All pushed to week 7.

This is the solo dev squeeze. You can ship features, or you can grow distribution. Doing both well in the same week is hard. I picked features this week. Next week the math has to flip.

Stack Overflow update

Quick note for anyone following the SO experiment from earlier weeks: I got a moderator warning. Not a ban — but a clear signal about the rules. The takeaway: you can use SO for self-promotion in narrow, well-defined cases (genuinely answering a question where your tool is one of several legitimate solutions, with full disclosure), but the bar is high and the risk/reward isn't great for backlinks specifically.

For now I'm not pursuing SO further as a backlink channel. Reddit, dev.to, Hashnode, and Indie Hackers continue to be the better mix.

Numbers, week 6

Indexed pages in GSC: 52 (up from 40+ last week)
Average position: 40+
Clicks from search: still climbing toward meaningful numbers — early indexing, niche keywords, give it time
Top traffic sources this week: SourceForge, Reddit, Threads (referral traffic is starting to compound from earlier posts)
Top countries: Ukraine, US, China, Germany

The GSC dashboard has been stuck on April 21 for five days, which is annoying — Google's lag is usually 2-3 days, not 5. I'll re-check next week before drawing conclusions.

What I'm noticing

A few things worth writing down so I remember them:

1. Niche landing pages get found. The PDF→PNG page didn't need a single backlink to start pulling traffic. SSG + clean URLs + targeted titles are doing the work. This validates the programmatic SEO bet — keep adding pages.

2. Referral traffic compounds slowly. Reddit comments I made weeks ago are still bringing people in. Threads posts from earlier in the buildinpublic series are now a source. None of this happens fast — but it does add up.

3. Redesigning is never "small". Three days for a converter UI redesign sounds like overkill until you realize that bad UX kills retention faster than missing features. The new format picker handles 15 → 40+ formats gracefully (it'll matter once I add more). The new buttons system dropped a lot of bundle weight.

Honest moment

I'm not going to pretend this week was full of breakthrough energy. I was heads-down and on autopilot for most of it. PDF integration was hard, the redesign ate the rest of the week, and I shipped instead of celebrating.

Sometimes building in public means publishing a week that was just work. No story arc, no aha moment. Just: kept moving, shipped the thing, paid the cost, here's what's next.

Week 7 plan

One goal: ship image → PDF and catch up on content.

That's it. No new initiatives, no shiny experiments. Close the PDF loop in both directions, and re-engage the community channels I dropped this week.

If you're a solo dev reading this — what's your current ratio of build vs grow? I'd love to compare notes.

*Convertify is a free, ad-free image converter built solo. If you've got files to convert, give it a try convertifyapp.net — and if you want to follow the build, I post weekly.

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.

DEV Community: Serhii Kalyna

AVIF encoding speed — the numbers nobody talks about

The compression story you already know

The encoding cost nobody talks about

The effort parameter an oversimplification

When to use which format

What this looks like in a converter pipeline

Browser support

The actual takeaway

Building in public, week 8: impressions exploded 71% and I think I know why

The numbers

What I think caused it

The position thing

What I built this week

Backlinks update

Organic search is now #1 traffic source

What's next (week 9)

From 0 to 72 indexed pages in 2 months: what Google actually does with new sites

Building in public, week 7: 19 pages, 189 missing FAQ entries, and organic search finally showing up

What actually happened vs. the plan

The schema_faq bug — 189 missing questions

Content expansion: three clusters

Frontend work: RelatedConversions upgrade

The numbers

What I'm noticing

Honest moment

Week 8 plan

Building in public, week 6: PDF support is live — but I had to sacrifice content for it

What shipped: PDF support (Wednesday)

How I integrated PDF in libvips

Landing pages

What didn't ship: content + image→PDF

Stack Overflow update

Numbers, week 6

What I'm noticing

Honest moment

Week 7 plan

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

The naive approach

Multi-page gets interesting

The rendering engine question

DPI clamping

What's next

Building in public — week 5

Week 5 vs week 4

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

The file size math nobody explains

Nine compression types — most people know two

Zero browser support is by design

The industries that actually use TIFF

The conversion numbers

What this did for my content

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

What I worked on this week

What actually drove the clicks

What's next

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

1. Convertify

2. Squoosh

3. Cloudinary

4. ILoveIMG

5. Convertio

6. EZGIF

Bottom line

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

The problem with alphabetical ordering

The scoring model: 70/30

How it works in practice

The component

What's next

Is HEIC Patent Risk Real for Small Web Services?

The question

My conclusion

The `effort` parameter an oversimplification