DEV Community: Bright Agbomado

TIL a PowerPoint file is just a zip — so I converted .pptx to Word entirely in the browser

Bright Agbomado — Mon, 25 May 2026 00:12:26 +0000

Most file converters upload your files to a server. I wanted to see how far I could get without one. Turns out: all the way.
The trick is that Office files aren't really binary blobs — a .pptx is a zip archive full of XML. Rename it to .zip, unzip it, and you'll find each slide sitting there as its own XML file. Once you know that, "convert PowerPoint to Word in the browser" stops sounding impossible.
Three libraries chained together, all running client-side:

import JSZip from 'jszip';
import { Document, Packer, Paragraph } from 'docx';

// 1. Crack open the .pptx (it's a zip)
const zip = await JSZip.loadAsync(file);

// 2. Walk each slide's XML for text
const parser = new DOMParser();
const slideFiles = Object.keys(zip.files)
  .filter((n) => n.match(/ppt\/slides\/slide\d+\.xml$/));

const paragraphs = [];
for (const name of slideFiles) {
  const xml = await zip.files[name].async('string');
  const doc = parser.parseFromString(xml, 'application/xml');
  const texts = doc.getElementsByTagName('a:t'); // <a:t> holds the text runs
  for (const t of texts) {
    paragraphs.push(new Paragraph(t.textContent));
  }
}

// 3. Write it out as a .docx
const out = await Packer.toBlob(new Document({
  sections: [{ children: paragraphs }],
}));

JSZip unzips, the browser's own DOMParser reads the slide XML ( tags are where the text lives), and docx writes the result to a .docx blob you can download. No server. No upload. No API key. The file never leaves your machine.

The nice side effect: because there's no upload cost, I let this one batch up to 25 files at once.

The honest tradeoff — pulling clean text and tables out of slide XML is the easy 80%; perfectly preserving every layout quirk is the hard 20%, and a pure-browser approach trades some of that fidelity for privacy and speed. For getting your slide content into an editable Word doc fast, it holds up well.

Live here if you want to try it: PowerPoint to word

I just launched RelahConvert on TinyLaunch

Bright Agbomado — Mon, 18 May 2026 13:59:28 +0000

After 3 months of solo building from Calgary, RelahConvert is live on TinyLaunch today.

RelahConvert is a free file converter and editor. The goal was simple: build a tool you can just open and use without thinking about it.
What's inside right now:

Image tools — convert, compress, resize, crop, background removal, passport photos
PDF tools — merge, split, rotate, compress, reorder, extract pages, add page numbers, watermark, crop, protect, unlock, extract images
Office tools — Word, Excel, and PowerPoint to PDF, plus PDF back to all three (just shipped last week)

Everything supports bulk processing. Available in 25 languages.

Why I built it

The honest answer is I wanted to learn by building something real, not by following tutorials. File conversion felt like a useful problem space — most existing tools either lock features behind paywalls, require accounts for basic use, or feel slow.
I'm not a trained developer. I started with no team, no funding, and no roadmap beyond "build something people might actually use."

Where it stands

Three months in, ~1,400 pages indexed, growing slowly. Real visits are still small. The product is functional and shipping, but the marketing and distribution side is the part I'm learning in public.
Today is a milestone — first proper launch on a directory. I have no expectation of cracking the top 3. The point was to do the thing, not to win.
If you want to check it out
The launch is live here: https://www.tinylaunch.com/launch/13598

Feedback welcome. I'm especially curious what people think about the no-account-required default — that was a deliberate choice and I'd love to hear if it works for you or feels weird.
Happy to support other indie launches too — drop yours in the comments.

hreflang tags were duplicating and I didn't notice for weeks

Bright Agbomado — Sat, 16 May 2026 14:24:57 +0000

Quick story about a bug I shipped without knowing for weeks.

Ahrefs flagged a warning: "More than one page for same language in hreflang — 161 pages affected." I went to view source on a tool page and counted the hreflang tags.

52.

Should have been 26.

What was happening

My build process correctly generated 26 hreflang tags per page — 25 languages plus x-default. Clean.

But then at runtime, JavaScript was doing this:

function injectHreflang(slug) {
  langs.forEach(lang => {
    const link = document.createElement('link')
    link.rel = 'alternate'
    link.hreflang = lang
    link.href = buildUrl(slug, lang)
    document.head.appendChild(link)
  })
}

appendChild. Not replace. Not "check if exists first." Just append, every time.

So every page shipped with 26 build-time tags in the static HTML, and then JS added 26 more on page load. Net result: 52 tags, every language listed twice pointing to identical URLs.

Why it mattered

Google's rule on duplicate hreflang: when a language appears twice with different URLs, it ignores both. When it appears twice with the same URL, Google still flags it as a signal-quality issue and downgrades trust in your hreflang setup overall.

I'd been wondering for weeks why non-English variants weren't ranking. Turns out I was telling Google "the French version is here AND also here" on 1,400+ pages.

The fix

I deleted the runtime injectHreflang() function entirely. Forty-one tool files were calling it — I removed the calls and the import everywhere.

The build-time tags were already correct. The runtime injection was redundant code from an earlier phase of the project that had outlived its purpose.

# Before
$ curl https://relahconvert.com/merge-pdf | grep hreflang | wc -l
52

# After
$ curl https://relahconvert.com/merge-pdf | grep hreflang | wc -l
26

The lesson

When something works at build time AND at runtime, it doesn't mean it's working twice as well. It usually means you have two systems fighting each other, and you'll only notice when an audit tool flags it.

You can see the fix in action on the RelahConvert PDF merger — view-source and count the hreflang tags yourself.

If you're building a multilingual site, check this on your own pages. Takes 10 seconds and the bug is more common than you'd think.

How I Added Pre-Rendering to a Vite Multi-Page App Without SSR

Bright Agbomado — Mon, 11 May 2026 00:20:14 +0000

I run RelahConvert, an online file conversion site with 50+ tools across 25 languages. Last week I noticed a problem in my Ahrefs audit: every single one of my 1,449 pages was flagged as "H1 missing" and "Low word count."
The pages weren't empty. They had H1s, descriptions, FAQs — all rendering correctly when you visited them. But here's what crawlers were seeing:

Yep. Empty.

The Setup

The site is a Vite MPA (multi-page app), not a SPA. Each tool has its own .html file. Tool-specific JavaScript injects the page content at runtime via document.querySelector('#app').innerHTML = template.
This works great for users. The page loads, JS runs, content appears. Fast and clean.
But it breaks for crawlers that don't execute JavaScript (Ahrefs, basic bots, social media scrapers like Facebook and X). They see an empty body. Even Google, which does run JS, has a delayed second-pass rendering that costs crawl budget and makes new pages slow to index.
The Usual Solutions Didn't Fit
The standard fixes for this problem:

Server-Side Rendering (SSR) — requires a runtime backend. I'm on Cloudflare Pages (static hosting). Not happening.
Static Site Generation (SSG) — would mean restructuring around a framework like Astro or Vike. Massive refactor for a site already shipping.
Pre-rendering with Puppeteer — spinning up a headless browser for every route during build. ~3-5 minute build time hit for 1,449 pages, plus heavy dependencies.

I wanted something lighter: just inject the SEO-relevant content (H1, description, FAQs) into the static HTML at build time, without re-implementing my entire UI in Node.
The Approach: Hybrid Pre-Render via Vite Plugin
I extended the existing build plugin to read my i18n dictionaries and write the SEO content directly into each HTML file. The interactive tool UI (drag-drop, canvas operations, conversion logic) stays JS-rendered — only the content that matters for crawlers gets baked in.
Rough shape of the plugin:

function preRenderPlugin() {
  return {
    name: 'pre-render-seo',
    apply: 'build',
    closeBundle() {
      const tools = ['compress', 'resize', 'merge-pdf', ...]
      const langs = ['en', 'fr', 'es', 'de', 'ar', ...]

      for (const tool of tools) {
        for (const lang of langs) {
          const i18n = loadI18n(lang)
          const seo = i18n.seo[tool]

          const html = readHTML(`dist/${lang}/${slugFor(tool, lang)}/index.html`)
          const injected = injectSEOContent(html, {
            h1: i18n.nav_short[tool],
            description: i18n.heroDesc,
            body: seo.body,
            faqs: seo.faqs,
          })

          writeHTML(path, injected)
        }
      }
    }

The content gets injected into the

placeholder. When JS runs at runtime, it replaces the contents with the interactive UI — but the pre-rendered version is what crawlers see.

Three Gotchas

Per-language metadata. My tool pages had hardcoded English
and , even on French URLs. Pre-rendering exposed this — crawlers were seeing French H1s with English titles. I had to extend the same plugin to resolve title and meta description per language from i18n at build time.
FOUC on per-language URLs. Initially I derived per-language URLs from the homepage template. JS at runtime detected the route and wiped the body to inject the tool. Result: brief flash of French content, then disappearance, then return. Fixed by switching per-language URLs to use the tool's own template as the base.
Cloudflare bot protection blocking social scrapers. Unrelated discovery — after fixing the OG tags, Facebook's Sharing Debugger returned 403. Cloudflare's Browser Integrity Check was challenging the Facebook scraper. The fix was a Cloudflare dashboard config, not code.

Result

Build time went from 22.7s to ~23s. Negligible. Every tool page now ships with proper H1, description, FAQs, and internal links in the static HTML across all 25 languages. Social previews work. Ahrefs and Google can read content on first crawl.

You can see the live result on the image compressor — view-source on the page shows the pre-rendered content.

The takeaway: if you're on Vite without a framework and need crawler-friendly HTML without going full SSG, a build-time plugin that injects SEO content into your existing structure is a surprisingly clean middle ground.

I Asked 500 Developers What AI They Use to Code. The Answers Were Surprising

Bright Agbomado — Fri, 10 Apr 2026 22:17:56 +0000

I've been building RelahConvert — a 37-tool image toolkit — entirely with Claude Code. No traditional coding background. Just prompts and persistence.

It got me thinking. Everyone claims to use AI for coding now. But which one actually wins in the real world?

So I started paying attention. Forums, Twitter, Reddit, dev.to comments. Here's what I actually found:

The honest breakdown:
GitHub Copilot — the corporate safe choice. Used by developers who already know how to code and want autocomplete on steroids. Nobody brags about it. Nobody hates it. It just exists.

ChatGPT — the first tool everyone tried. Still popular for quick questions and explaining code. But people rarely use it to actually build full projects anymore.

Cursor — the new darling. Every developer on Twitter seems to be using Cursor right now. It's eating Copilot's lunch among serious developers.

Claude Code — the one nobody talks about publicly but keeps appearing in solo founder stories. Especially for people building full products from scratch, not just autocompleting lines.

Gemini — Google's answer. Technically impressive. Nobody seems emotionally attached to it.

The pattern I noticed:
Developers who already code → use Copilot or Cursor to go faster
Non-developers building products → use Claude Code or ChatGPT to actually ship
Two completely different use cases. Two completely different tools winning.

The controversial part:
The "vibe coder" debate is pointless.
People who gatekeep coding — "you're not a real developer if you use AI" — are the same people who said "you're not a real developer if you use Stack Overflow" in 2010.
The output is what matters. I shipped 37 tools in 6 weeks. I don't know what a for loop looks like from memory. My users don't care.

The real question nobody asks:
Not "which AI do you use?"
But "did you actually ship anything?"
Most people collecting AI coding tools haven't shipped a single thing. The tool isn't the flex. The product is.

What are you actually using to build — and have you shipped something with it? 👇

9 Things I Did Wrong Building My Image Tool (And What Actually Fixed Them)

Bright Agbomado — Fri, 03 Apr 2026 22:12:32 +0000

I've been building Relahconvert — a free browser-based image toolkit — for about a month now. 37 tools, 25 languages, zero backend for most of it.
Sounds clean. It wasn't 😄
Here are 9 real mistakes I made and what actually solved them.

"I'll just use a library for that" → Canvas API
My first instinct for image processing was to reach for a library. Turns out the browser's Canvas API handles resize, crop, flip, grayscale, and more natively. No dependencies. No bundle size. Just pixels.
js const ctx = canvas.getContext('2d'); ctx.drawImage(img, 0, 0, newWidth, newHeight); canvas.toBlob(blob => downloadFile(blob), 'image/jpeg', 0.9);
I now use this for 90% of my tools.
"Dark mode needs JavaScript" → prefers-color-scheme
I built a whole JS toggle system before realizing the browser already knows what the user wants.
css@media (prefers-color-scheme: dark) {
:root {
--bg: #1a1a1a;
--text: #f0f0f0;
}
}
Still kept the manual toggle — but the default is now instant and correct.
"I need a backend for file downloads" → URL.createObjectURL
I thought serving processed images required a server. Nope.
jsconst url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = 'converted.png';
a.click();
URL.revokeObjectURL(url);
Everything stays in the browser. No uploads. No server costs. Users love the privacy angle.
"Batch processing will kill performance" → Web Workers
Processing 25 images at once was freezing the UI. Web Workers run in a separate thread — the page stays responsive while the heavy lifting happens in the background.
jsconst worker = new Worker('process.js');
worker.postMessage({ imageData, format: 'webp' });
worker.onmessage = e => renderResult(e.data);
Game changer for batch tools.
"I need an API for compression" → canvas.toBlob quality param
I almost paid for a compression API. Then I noticed toBlob has a quality parameter.
jscanvas.toBlob(blob => save(blob), 'image/jpeg', 0.7);
0.7 gives you roughly 60-70% size reduction with barely visible quality loss. Free. Built-in. Already there.
"RTL Arabic will break my layout" → CSS logical properties
Supporting 25 languages including Arabic felt terrifying. Logical properties made it manageable.
css.tool-container {
margin-inline-start: 1rem;
padding-inline: 1.5rem;
}
One declaration. Works LTR and RTL automatically.
"I'll handle the API key in the frontend" → Cloudflare Workers
I exposed an API key in my frontend. Bots found it within days 😬
The fix: a Cloudflare Worker as a proxy. Your key lives server-side, requests go through the worker, users never see it.
jsexport default {
async fetch(request) {
const response = await fetch('https://api.remove.bg/v1.0/removebg', {
method: 'POST',
headers: { 'X-Api-Key': API_KEY },
body: await request.formData()
});
return response;
}
}
Lesson learned the hard way.
"Multi-language SEO is just hreflang tags" → it's not
I had hreflang conflicts with canonical tags for weeks and couldn't figure out why my impressions were dropping. Canonicals, sitemaps, and hreflang all need to agree with each other.
html

One wrong canonical and Google ignores your entire language setup.
"More tools = more traffic" → wrong
I built 37 tools thinking volume would win. But 37 unindexed tools is worth less than 5 indexed and ranking ones.
Now I ask before building: is this keyword searchable? Is the difficulty realistic for my domain authority? Does it solve a real problem?
Tools are only as valuable as the traffic they attract.

What I'm still figuring out

Supabase auth across 25 languages
Getting Google to index all 950 pages faster
Whether PDF to PNG is worth the complexity

Building in public is humbling. But the browser is genuinely more powerful than most tutorials let on — and that's what makes solo projects like this possible.

I launched a free image tool 30 days ago. Here's what Google did next

Bright Agbomado — Tue, 31 Mar 2026 23:12:49 +0000

30 days ago I launched RelahConvert — a free browser-based image toolkit with 37 tools across 25 languages.

I thought the hard part was building it. I was wrong.

The First Week Felt Amazing

Impressions climbed daily. Pages were getting indexed fast.
GSC was showing 100-150 impressions per day. I thought I was
onto something.

Then Google pulled the rug.

The Drop Nobody Warns You About

Around day 20, impressions crashed to near zero. Some days
literally 0 or 1 impression.

Meanwhile GSC kept indexing more pages. 207 indexed. Then
952 Pages being discovered.

But impressions? Flatline.

I spent days trying to figure out what I did wrong.

What I Actually Found

Running a Semrush audit revealed three real issues:

48 hreflang conflicts — my language pages had canonical
tags pointing to the English version instead of themselves.
Google was getting contradictory signals on 48 pages.

24 incorrect sitemap URLs — a trailing slash
inconsistency between my sitemap and canonical tags.
The sitemap said /compress/ but the canonical said /compress.

Result: Google was seeing 3 different signals for the
same URL and didn't know which one to trust.

The Fix

Each language page canonical now points to itself:

/fr/compress/ canonical → relahconvert.com/fr/compress/
/ar/compress/ canonical → relahconvert.com/ar/compress/

And the sitemap now consistently matches the canonical
format across all 1,075 URLs.

What Happened After

External backlinks jumped from 2 to 10 in GSC.
Internal links jumped from 531 to 1,770.
FAQ rich results grew from 38 to 57.

Impressions? Still recovering. I learnt Google needs 2-4 weeks
to recrawl and reassess after canonical changes.

What I Learned

Google doesn't punish you for fixing things. But it
does take time to process changes — especially on a
domain that's only 30 days old.

The hardest part isn't the technical fixes. It's
watching your numbers flatline while knowing the
fix is in and you just have to wait.

Where I Am Now

207 pages indexed
57 valid FAQ rich results
10 external backlinks
1,770 internal links
Position 76 average (working on it)

Day 30. Still building. Still waiting.

If you're in the same spot — new site, confusing GSC
data, impression drops that make no sense — you're
probably not doing anything wrong. Google just takes
time with new domains.

Building RelahConvert in public

How I Got 149 Pages Indexed in 27 Days With a New Domain

Bright Agbomado — Sat, 28 Mar 2026 23:23:10 +0000

When I launched RelahConvert — a free browser-based image toolkit — I had one big SEO concern: would Google even bother indexing a brand new domain with hundreds of pages?

27 days later, 149 pages are indexed with 816 still pending.
Here's exactly what I did and what I learned.

The Site Structure

RelahConvert has 37 image tools across 25 languages. That's
theoretically 925 pages total. Getting Google to find and
index all of them quickly required being intentional about
a few things.

1. Submit a Sitemap Immediately

The first thing I did after launching was submit a sitemap
to Google Search Console. This tells Google exactly which
pages exist and where to find them.

In Vite, generating a sitemap is straightforward with
vite-plugin-sitemap:

import sitemap from 'vite-plugin-sitemap'

export default {
  plugins: [
    sitemap({
      hostname: 'https://relahconvert.com'
    })
  ]
}

Submit it in GSC under Sitemaps and Google will start
crawling within days.

2. Strong Internal Linking

Every tool page on RelahConvert links to related tools
through the navbar, footer, and a "What's Next" section
after each conversion. This means Googlebot can crawl
from any page to every other page easily.

GSC confirmed 531 internal links across the site. That's
Googlebot's roadmap.

3. Request Indexing for Priority Pages

For your most important pages don't just wait — request
indexing manually in GSC using the URL Inspection tool.

Enter the URL → click "Request Indexing" → Google
prioritizes crawling that page.

I did this for my core tool pages and they showed up in
results within days.

4. FAQ Structured Data

Every tool page has FAQ schema markup. Within 27 days
GSC showed 48 valid FAQ rich results with zero errors.

This doesn't directly cause indexing but it signals to
Google that your pages are well structured and trustworthy.

5. Be Patient With Multilingual Pages

With 25 languages, most of my non-English pages are still
in the "Discovered — not yet indexed" queue (964 pages).
Google indexes the primary language first then works
through translations.

Make sure your hreflang tags are correct so Google
understands the relationship between language versions.

What's Actually Indexed After 27 Days

149 pages indexed
964 discovered but pending
1,140 impressions in 28 days
Position 76 average (still early)

The indexing is happening. The rankings take longer.

The Honest Reality

Getting pages indexed quickly is the easy part. Getting
them to rank is the slow part that requires backlinks,
time, and domain authority that a 27 day old site simply
doesn't have yet.

But you can't rank what isn't indexed. Step one is done.

37 free image tools at RelahConvert

How I Added Dark Mode to a 37-Tool Vite SPA in One Prompt

Bright Agbomado — Tue, 24 Mar 2026 23:41:18 +0000

I've been building RelahConvert — a browser-only image converter
with 37 tools — and yesterday I decided to add dark mode.

I was expecting it to take hours. It took minutes.

Here's exactly how it works and what I learned.

The Problem With Hardcoded Colors

Most projects start with colors scattered everywhere:

background: #ffffff;
color: #1a1a1a;
border: 1px solid #e0e0e0;

When you have 37 tool pages, finding and replacing every
hardcoded color manually would take forever. There had to be
a better way.

The Solution: CSS Variables + data-theme

The entire dark mode system comes down to two things:

1. Define all colors as CSS variables

:root {
  --bg: #ffffff;
  --text: #1a1a1a;
  --card: #f5f5f5;
  --border: #e0e0e0;
}

[data-theme="dark"] {
  --bg: #18181b;
  --text: #f4f4f5;
  --card: #27272a;
  --border: #3f3f46;
}

2. Toggle the attribute on the root element

const toggle = () => {
  const current = 
    document.documentElement.getAttribute('data-theme');
  const next = current === 'dark' ? 'light' : 'dark';
  document.documentElement.setAttribute('data-theme', next);
  localStorage.setItem('theme', next);
}

That's the whole system.

Remembering the Preference

You also want to respect the user's OS preference on first
visit, then let them override manually:

// On page load
const saved = localStorage.getItem('theme');
const prefersDark = 
  window.matchMedia('(prefers-color-scheme: dark)').matches;
const theme = saved || (prefersDark ? 'dark' : 'light');
document.documentElement.setAttribute('data-theme', theme);

The Toggle Button

A simple sun/moon icon in the navbar:

const icon = theme === 'dark' ? '☀️' : '🌙';

Place it top right — that's where users expect it.

Tips for Dark Mode That Doesn't Look Weird

A few things I learned:

Never use pure black (#000000) — use #18181b or similar. Pure black feels harsh.
Never use pure white text — use #f4f4f5. Pure white on dark backgrounds causes eye strain.
Give cards depth — make cards slightly lighter than the background so elements don't flatten out.
Watch out for images — if users upload images with white backgrounds, they'll float awkwardly on dark pages. Keep preview areas neutral.

The Result

38 tool pages, all consistently dark, zero hardcoded color
conflicts. The site went from feeling like a utility tool to
feeling like a proper app.

If you're building a Vite SPA and haven't added dark mode yet
— it's simpler than you think. One CSS variable system and a
10-line toggle is all it takes.

Built with Vite. All processing is browser-only — files never
leave the device.

Check it out at RelahConvert

I launched a free image tool site 3 weeks ago. Here's what actually happened.

Bright Agbomado — Mon, 23 Mar 2026 11:55:59 +0000

3 weeks ago I launched relahconvert.com — a free browser-based image converter with 37 tools and 25 languages.
Here's the honest numbers so far:

1,090 Google impressions
11 real clicks
Position 76 average
2 external backlinks (both from dev.to)
109 pages indexed out of 843

Not viral. Not impressive. But moving in the right direction.
What I thought would happen:
Launch, get traffic, make money.
What actually happened:
Built 37 tools. Realized no one can find you without backlinks. Realized backlinks require effort. Realized SEO takes months not days.
What I learned:
Building is the easy part. Distribution is the real work.
Everyone talks about what they built. Nobody talks about the 3 weeks after launch when Google doesn't care you exist yet.
I'm documenting the whole journey — the tools, the SEO, the slow grind of getting traffic from zero.
If you're building something right now and wondering why nothing is happening yet — you're not alone.
Try the tools here: https://relahconvert.com

I built a free passport photo maker for 160+ countries — no server uploads

Bright Agbomado — Sat, 21 Mar 2026 18:59:06 +0000

I just added a passport photo maker to RelahConvert — here's what makes it different.
Most passport photo tools upload your photo to their server, process it, then send it back. That means your face is sitting on some random server somewhere.
Mine works entirely in the browser. The photo never leaves your device.
What it does:

Supports 160+ countries with correct dimensions
Auto-detects and crops to head and shoulders
Removes background using AI (runs locally in browser)
Downloads single photo or printable 4×6 sheet
Available in 25 languages.

The hard part was getting the crop right for every photo type — full body, portrait, headshot. Still not perfect but works well for standard portrait photos.
Built with vanilla JS + Canvas API + @imgly/background-removal for the AI part.
Try it here: Try it here: https://relahconvert.com/passport-photo
Would love feedback — especially if the crop doesn't work for your photo type.

I built a free browser-based image converter — no uploads, files never leave your device

Bright Agbomado — Sat, 07 Mar 2026 14:15:44 +0000

I've been frustrated with image tools that upload your files to their
servers. You never really know what happens to your photos after that.

So I built RelahConvert — a completely free image tool suite that runs
100% in your browser. No uploads, no servers, no accounts required.

What it does

Compress images — reduce file size while keeping quality
Resize images — by pixels or percentage
Convert between JPG, PNG and WebP formats
Convert images to PDF

All 10 tools are free and your files never leave your device. Everything
runs using the browser's built-in Canvas API.

How it works technically

Instead of sending files to a server, I use the HTML5 Canvas element to
process images directly in the browser. The user picks a file, Canvas
reads the pixel data, applies the transformation, and outputs the result
— all locally.

For the PDF conversion I used a lightweight JS library to bundle images
into a proper PDF structure without any server involvement.

What's next

I'm adding 30 more tools over the next few weeks including:

GIF, BMP and TIFF conversions
Crop, rotate and flip
Grayscale, brightness and contrast adjustments
Watermark tool
EXIF metadata remover

Try it

RelahConvert — completely free, no account needed.

Would love any feedback from the dev community on the approach or
any tools you'd like to see added.