DEV Community: Muhaymin Bin Mehmood

I Don't Want to Build 100 Random Tools for SEO

Muhaymin Bin Mehmood — Sun, 13 Sep 2026 14:00:00 +0000

There is a tempting strategy for utility websites:

Build a lot of tools.

Then build more.

Then keep going until the sitemap is enormous.

You can easily imagine the backlog:

PNG converter
JPG converter
QR generator
word counter
percentage calculator
JSON formatter
random picker
password generator
...

Some of those pages may attract search traffic.

But I do not think "more tools" automatically means "better product."

Traffic and product value are different

A page can rank.

A page can get clicks.

A page can even generate ad revenue.

None of that guarantees the user has a reason to return.

A collection of unrelated utilities often creates isolated sessions:

Google search
   ↓
Use tiny tool
   ↓
Leave

That can be a valid business.

It is just not the product I want to build.

The question I now ask

Instead of:

"What other tool has search volume?"

I prefer:

"What does the user need immediately before or after the current task?"

That changes the roadmap.

Imagine the user is preparing product images.

Their workflow may be:

Receive supplier photos
        ↓
Resize
        ↓
Convert format
        ↓
Compress
        ↓
Prepare marketplace variants
        ↓
Generate product barcodes

Those tools belong near each other.

They share a user.

They share context.

They may eventually share data and automation.

That is a product.

Marketing has the same pattern

A marketer may do:

Create campaign image
        ↓
Resize for channels
        ↓
Create landing URL
        ↓
Add tracking
        ↓
Shorten link
        ↓
Generate QR

Again, the tools are connected.

A social resizer and a QR-code generator may look unrelated from a technical perspective.

From the user's campaign workflow, they can be part of the same job.

Connected workflows create stronger expansion

If tools are connected, you can eventually build experiences like:

Upload one campaign asset
   ↓
Generate 8 platform versions
   ↓
Create tracked destination
   ↓
Generate QR
   ↓
Export campaign package

Now the product is not a directory.

It is a workflow engine.

That is much more interesting to me.

SEO should support the product

I still care about search.

Utility products can benefit enormously from search intent because users often describe the exact job they need done.

Examples:

webp to jpg
bulk image converter
social media image resizer
barcode generator
qr code generator

Those are useful entry points.

But the content should lead into a coherent product experience.

The goal is:

Search intent
   ↓
Useful free tool
   ↓
Related workflow
   ↓
Return usage

not:

Search intent
   ↓
Random tool
   ↓
Ad
   ↓
Goodbye

This is the direction behind BatchSet

I am building BatchSet around image, e-commerce, and marketing workflows.

The current toolkit includes areas such as:

image conversion
bulk conversion
resizing
social-media preparation
QR generation
URL shortening
barcode generation

You can browse the current tool collection here:

👉 BatchSet Tools

The goal is not to add every utility that exists on the internet.

The goal is to make the workflows around these users increasingly connected.

A simple roadmap filter

Before building a new tool, I now like asking:

1. Does the existing audience need it?

If the current users are e-commerce sellers, marketers, developers, or content teams, does the new tool serve them?

2. Does it connect to an existing workflow?

Can the output of one tool become the input of another?

3. Can it share infrastructure?

Can the tool reuse:

file pipeline
account system
analytics
export logic
presets
batch processing

4. Does it improve retention?

Will existing users have another reason to return?

5. Is search demand a bonus or the only reason?

If the only argument is "keyword volume," I become more cautious.

The compounding effect

Connected tools can compound.

A user who arrives for conversion may discover bulk processing.

A user who arrives for social resizing may need QR codes.

A seller who arrives for image optimization may need barcodes.

The platform becomes more valuable because the tools reinforce one another.

That is different from simply increasing page count.

The risk

There is also a danger in "all-in-one."

Products can become bloated.

Navigation becomes confusing.

Features become shallow.

The answer is not to connect everything.

The answer is to connect workflows that genuinely belong together while keeping individual tools fast and understandable.

That balance is hard.

But it is a better problem than maintaining 500 unrelated utilities nobody remembers.

Final thought

SEO can tell you what people search for.

It should not be the only thing deciding what your product becomes.

For me, the stronger question is:

Can this new tool make an existing user's workflow meaningfully better?

If the answer is yes, search traffic can become an acquisition channel for a real product.

If the answer is no, I am probably just adding another page to the internet.

I Built the Signup Wall First. Then I Realized It Was the Wrong Feature.

Muhaymin Bin Mehmood — Sat, 12 Sep 2026 14:00:00 +0000

There is a very normal SaaS flow:

Landing page
   ↓
Create account
   ↓
Verify email
   ↓
Enter app
   ↓
Try feature

I built a version of that pattern too.

Then I started questioning the most basic part of it.

Why should somebody create an account before they know whether the tool solves their problem?

For some products, registration is essential.

For others, it is just inherited behavior.

The product question I should have asked earlier

Instead of asking:

"How do I get more users to sign up?"

I should have asked:

"Why does this action require an account at all?"

Those are completely different questions.

The first assumes the wall should exist.

The second forces you to justify it.

When registration makes sense

Accounts are valuable when users need persistent state.

For example:

saved projects
billing
team collaboration
usage history
API keys
shared workspaces
analytics dashboards
cloud storage
preferences synced across devices

In those cases, identity is part of the product.

When registration can be unnecessary

Now consider a simple utility workflow:

Open tool
Drop image
Convert
Download
Leave

What persistent state is required?

Maybe none.

If the tool can deliver value immediately, forcing:

name → email → password → verification

before the first successful result is pure friction.

The user did not arrive because they wanted a relationship with your SaaS.

They arrived because they wanted a file converted.

The "capture the email" instinct

This is where SaaS incentives can fight user incentives.

The business wants:

leads
accounts
retargeting
upgrade opportunities

The user wants:

the result

If you optimize only for account creation, you can accidentally reduce the number of people who ever experience the product's value.

That is a bad trade.

Let value come first

A better model for some utilities is:

Try core workflow
   ↓
Get successful result
   ↓
Offer account for persistent benefits

Now registration has context.

Instead of:

"Create an account to continue."

you can say:

"Create an account if you want history, analytics, saved settings, or higher limits."

That feels much more honest.

This changed how I think about BatchSet

BatchSet includes browser-based image and marketing utilities.

For common image conversion, I did not want account creation to be the first task.

The user should be able to understand the product by using it.

That is why the basic workflow emphasizes:

no mandatory signup for common conversion
no watermark
browser-based processing for supported basic conversions

You can see the current product here:

👉 BatchSet

I am the person building it, so this is not a neutral product review. It is a product-design lesson from working on it.

Friction is not only forms

Signup walls are obvious friction.

There are quieter forms too:

too many settings before first action
unclear file limits
fake "free" buttons
surprise watermarks
download gates
forced tutorials
unnecessary onboarding modals
slow confirmation steps

Each one delays the moment where the user says:

"Yes, this solved my problem."

The activation event matters

Every product has some version of an activation event.

For a file converter, it may be:

Successfully download the converted file.

For a project-management product:

Create the first project and invite a teammate.

For an analytics product:

Connect a data source and see the first useful dashboard.

Your onboarding should help users reach that event.

If a signup form is required to support it, fine.

If the signup form only delays it, reconsider.

A useful experiment

Take your current funnel and write every step:

Visit landing page
Click CTA
Choose plan
Create account
Verify email
Complete onboarding
Upload file
Configure settings
Process
Download

Now ask of every step:

Does this help the user reach value, or does it only help us?

Some business-required steps are unavoidable.

But the question is still worth asking.

Final thought

Not every SaaS should remove registration.

But every SaaS should justify registration.

"Because SaaS products have accounts" is not a strong reason.

The best onboarding is not the one that collects the most information.

It is the one that gets the right user to a meaningful result with the least unnecessary friction.

The Moment Your Tool Supports 100 Files, It Becomes a Different Product

Muhaymin Bin Mehmood — Fri, 11 Sep 2026 14:00:00 +0000

A tool that processes one file and a tool that processes 100 files may share the same conversion function.

They are still different products.

The moment users can drop a large batch into your app, almost every surrounding decision changes.

One-file logic

A one-file flow can be brutally simple:

const result = await processFile(file);
download(result);

The UI can show a spinner.

If the operation fails, show an error.

Done.

Now add 100 files

The naive implementation becomes:

const results = await Promise.all(
  files.map(processFile)
);

This looks elegant.

It can also be a terrible idea.

If every file is a large image, you may suddenly decode dozens or hundreds of high-resolution bitmaps simultaneously.

Memory spikes.

The tab freezes.

Mobile devices suffer.

The browser may kill the page.

Bulk support requires resource management.

Controlled concurrency

A better design uses a limited number of active jobs.

Conceptually:

Queue: 100 files

Active:
[1] processing
[2] processing
[3] processing
[4] processing

When [2] finishes:
take next item from queue

This gives you a lever.

You can adjust throughput without creating unbounded pressure.

The correct limit depends on:

average file size
image dimensions
CPU cost
memory usage
target device class

The important principle is simple:

Maximum parallelism is not the same thing as maximum useful performance.

Progress becomes a first-class feature

With one file, a spinner is enough.

With 100 files, the user wants answers:

How many are complete?
Which file is processing?
Did any fail?
Can I cancel?
Can I download completed outputs?
Is the app stuck?

A useful progress model might show:

63 / 100 complete
4 processing
31 waiting
2 failed

That is much more informative than an indeterminate loader.

Errors should not kill the batch

Another difference:

If 1 file fails out of 100, should the entire job fail?

Usually not.

Bulk operations need per-item error isolation.

A better result can look like:

✓ photo-001.jpg
✓ photo-002.jpg
✗ broken-file.tiff
✓ photo-004.jpg

Then the user can retry or inspect only the failed items.

This is a general batch-processing principle:

One bad record should not destroy 99 good results unless atomicity is actually required.

Download UX changes too

Downloading 100 files one by one is technically possible.

It is also horrible UX.

Users expect one packaged output.

That is why ZIP generation naturally appears in bulk tools.

The workflow becomes:

process items
   ↓
collect outputs
   ↓
package
   ↓
download once

The packaging step becomes part of the product.

Naming becomes important

Single-file tools can get away with generic output names.

Bulk tools cannot.

If the user uploads:

product-01.jpg
product-02.jpg
product-03.jpg

the outputs should remain recognizable:

product-01.webp
product-02.webp
product-03.webp

Otherwise the user saves time during conversion and loses it again during file cleanup.

Cancellation matters

A 500-file job may take long enough that the user changes their mind.

A production-quality system should think about cancellation.

In browser code, that may involve:

abort signals
worker termination
queue state
cleanup of temporary objects

The UX should clearly distinguish:

queued
active
completed
cancelled
failed

Memory cleanup is part of correctness

Browser image processing often creates:

ImageBitmap
canvas buffers
object URLs
blobs

If you keep unnecessary references alive, memory usage can climb during a large batch.

Bulk testing should include long runs, not just successful 5-file demos.

This problem shaped BatchSet

One of the reasons I built BatchSet's Bulk Image Converter was that I wanted the workflow to focus on the batch as a unit.

Not:

"Here's a converter that technically accepts multiple files."

But:

"How should the app behave when the batch itself is the user's job?"

That framing changes the product.

A checklist for bulk tools

If you are adding multi-file support, I would review:

[ ] controlled concurrency
[ ] per-item status
[ ] total progress
[ ] failure isolation
[ ] retry behavior
[ ] cancellation
[ ] predictable filenames
[ ] memory cleanup
[ ] one-click packaged download
[ ] mobile / low-memory testing

Final thought

"Supports multiple files" is not a checkbox.

It is an architecture decision.

The processing function may be the same.

Everything around it changes.

And that is why the moment your app supports 100 files, it becomes a different product.

Code 128 vs EAN-13 vs UPC-A: The Barcode Question People Ask Too Late

Muhaymin Bin Mehmood — Thu, 10 Sep 2026 14:00:00 +0000

A barcode generator can create an image in seconds.

That is not the hard part.

The hard part is answering:

What type of barcode should this number become?

If you choose the barcode format after designing labels, building inventory screens, and printing packaging, you are asking the question too late.

Three formats appear constantly in practical workflows:

UPC-A
EAN-13
Code 128

They solve different problems.

UPC-A

UPC-A is strongly associated with retail product identification, especially in North American contexts.

It represents numeric data in a fixed structure.

If you are dealing with retail products intended for established point-of-sale ecosystems, UPC may be part of the required workflow.

Important:

Generating a UPC-looking barcode does not mean you have created a legitimate registered retail product identifier.

The number itself and its ownership/registration are separate from rendering the bars.

EAN-13

EAN-13 is also used for retail product identification and is common internationally.

Like UPC, it is not just "a barcode style."

It participates in a broader product-identification system.

This distinction matters because developers sometimes build a generator that accepts any 13 digits and assume the business problem is solved.

Technically, the image may be valid.

Operationally, the identifier may not be.

Code 128

Code 128 is more flexible for internal and logistics workflows.

It can represent a broader set of characters and is commonly useful for:

warehouse labels
internal stock IDs
shipment references
bin locations
custom inventory systems
operational tracking

If you control both the system generating the identifier and the system scanning it, Code 128 can be a practical option.

Retail identity vs internal identity

This is the easiest mental model.

Retail barcode

The identifier needs to participate in a standardized external ecosystem.

Examples:

UPC-A
EAN-13

Internal barcode

The identifier mainly needs to work inside your own operational system.

Example:

Code 128

That distinction often tells you more than a long barcode-spec comparison.

Check digits are not random

UPC and EAN systems commonly include a check digit.

The purpose is error detection.

If a digit is mistyped or scanned incorrectly, the checksum can help identify that the value is invalid.

This is useful because retail scanning needs to be reliable at high speed.

The exact calculation is deterministic.

That means a good barcode tool should not simply draw bars.

It should validate the structure where appropriate.

The generator is not the registry

This deserves repeating because it causes real confusion.

A barcode generator can:

render a valid symbol
calculate or validate certain checksums
export a label image

It cannot automatically assign your business a globally recognized retail product number.

That comes from the relevant numbering/registration process.

Think of it like a QR code generator.

The QR tool can encode a URL.

It does not give you ownership of the domain inside that URL.

Batch generation is where things become useful

Generating one barcode is simple.

Generating 2,000 warehouse labels is a workflow.

At that point you care about:

importing identifiers
validating values
naming outputs
generating consistently
printing labels
matching SKU data

The product problem changes from "draw barcode" to "prepare barcode assets at scale."

I built a Barcode Generator in BatchSet because I wanted the generator to sit alongside the other e-commerce utilities instead of becoming another isolated website.

You can also see the broader catalog workflow here:

👉 BatchSet for E-Commerce

A practical decision table

Need	Likely direction
Retail product sold through established external systems	UPC-A or EAN-13 depending on the required standard
Internal warehouse identifier	Code 128
Shipment / logistics reference	Often Code 128 or another logistics-specific standard
Arbitrary internal alphanumeric value	Code 128
Globally recognized retail identity	Use the appropriate registered numbering process, not a random generated number

This table is intentionally simplified.

Real supply chains can have additional GS1 requirements and industry-specific standards.

What developers should ask before implementation

Before building barcode support, ask the business:

Who scans the code?
What system receives the value?
Is the identifier internal or externally standardized?
Does the value already exist?
Is registration required?
What printers and scanners are used?
What label size is available?
Do we need human-readable text under the barcode?

These questions can prevent weeks of redesign.

Final thought

Choosing a barcode is not primarily a graphics decision.

It is an identity-system decision.

The bars are just the machine-readable representation.

Start with what the identifier means, who owns it, and where it needs to work.

Then choose the barcode format.

A QR Code Without Tracking Is a Missed Experiment

Muhaymin Bin Mehmood — Wed, 09 Sep 2026 14:00:00 +0000

QR codes are everywhere again.

Menus.

Packaging.

Flyers.

Booths.

Business cards.

Posters.

But a lot of QR campaigns stop at:

QR → homepage

That works technically.

It is weak analytically.

If you are printing 10,000 flyers, you should be able to answer:

Did those flyers generate meaningful traffic?

That requires thinking beyond the QR image.

The QR code is only the transport layer

A QR code stores or represents data.

In a marketing campaign, that data is usually a URL.

The useful architecture is:

Campaign destination
        ↓
Tracking parameters
        ↓
Short / managed URL
        ↓
QR code
        ↓
Printed material
        ↓
Scan
        ↓
Analytics

The QR graphic itself is not the analytics strategy.

The URL is.

Start with UTMs

A simple campaign URL might look like:

https://example.com/pricing
  ?utm_source=flyer
  &utm_medium=qr
  &utm_campaign=september_launch

Now analytics can distinguish that traffic from:

organic search
LinkedIn
email
direct visits
another offline campaign

The exact naming convention matters less than consistency.

Use a naming system

Do not create this:

utm_campaign=flyer1
utm_campaign=newflyer
utm_campaign=septthing

A predictable structure is much easier to analyze.

For example:

utm_source=offline
utm_medium=qr
utm_campaign=2026_september_launch
utm_content=store_counter

Then another placement can be:

utm_content=product_packaging

and another:

utm_content=trade_show_banner

Now the campaign is comparable by placement.

Why short links help

UTM URLs are ugly.

A raw tracked URL can become very long.

The QR code can still encode it, but a managed short URL gives you useful flexibility:

short URL
   ↓
tracked destination

Depending on the system, you may be able to change the destination later without replacing the printed visual.

Even when you cannot, short links are easier to manage and communicate.

They are also useful when the same campaign link is shared in text.

Separate campaigns by physical placement

This is where the data becomes interesting.

Imagine a coffee shop has three QR placements:

table tent
receipt
front-door poster

If all three use the same QR URL, you only know total scans.

If each uses a distinct tracked link, you can learn which placement actually works.

For example:

utm_content=table_tent
utm_content=receipt
utm_content=door_poster

Now the physical world becomes testable.

Do not send every QR to the homepage

This is a common mistake.

The scan should continue the user's context.

A QR on a product package might go to:

setup instructions
warranty registration
reorder page
authenticity verification
product tutorial

A QR at an event might go to:

demo booking
event-specific landing page
downloadable resource

A QR in a restaurant might go to:

menu
feedback form
loyalty signup

The destination should match the reason someone scanned.

Test before printing

A print mistake is expensive.

Before approving a QR asset:

scan it on multiple phones
test normal and low-light conditions
verify the URL
verify UTM parameters
verify redirect behavior
test the final physical size
leave sufficient contrast and quiet space

A QR that works at 800px on your monitor may fail when printed tiny on packaging.

A workflow I am building

I wanted QR generation and link tracking to live closer together, because marketers often need both.

So BatchSet includes:

And the marketing-focused collection is here:

👉 BatchSet for Marketers

I build BatchSet, so this is the transparent product mention.

Suggested UTM template

If you need a starting convention:

utm_source=<channel-or-placement>
utm_medium=qr
utm_campaign=<year_month_campaign>
utm_content=<creative-or-location>

Example:

utm_source=conference
utm_medium=qr
utm_campaign=2026_09_product_launch
utm_content=booth_banner

The important part is that your team uses the same system repeatedly.

Final thought

Offline marketing does not have to be unmeasurable.

A QR code can connect physical material to digital behavior.

But only if you design the tracking before you print.

So next time you generate a QR code, do not stop at:

"Does it scan?"

Also ask:

"Will we know what happened after it scanned?"

One Design, 28 Outputs: The Engineering Problem Behind a Social Media Resizer

Muhaymin Bin Mehmood — Tue, 08 Sep 2026 14:00:00 +0000

A social media resizer sounds like a tiny utility.

Upload an image.

Pick Instagram.

Resize.

Done.

Then you try to support multiple platforms and discover the real problem.

The problem is not resizing.

The problem is turning one source design into many different aspect ratios without making the outputs look broken.

Start with presets as data

Do not hard-code every platform into UI logic.

A better design starts with a preset model.

Conceptually:

const presets = [
  {
    id: "instagram-portrait",
    platform: "Instagram",
    label: "Portrait Post",
    width: 1080,
    height: 1350
  },
  {
    id: "tiktok-vertical",
    platform: "TikTok",
    label: "Vertical",
    width: 1080,
    height: 1920
  }
];

Now the UI is generated from data.

That makes it easier to:

add new presets
update dimensions
group by platform
search presets
export multiple targets

The preset list becomes product configuration rather than scattered conditionals.

The hard part: aspect ratios

Suppose the source is a wide 16:9 graphic.

Now the user asks for a 9:16 vertical output.

You have three basic choices.

1. Contain

Scale the whole source until it fits.

Result:

nothing is cropped
empty space may appear

2. Cover

Scale until the entire target is filled.

Result:

no empty space
part of the source is cropped

3. Stretch

Force the source to exactly match the target.

Result:

no empty space
no crop
distorted content

For most creative work, stretch is the dangerous one.

Humans notice distorted faces, logos, circles, and product shapes immediately.

Crop position becomes a UX feature

"Cover" is not enough.

You also need to decide which part gets cropped.

Center crop is a reasonable default:

[     SOURCE IMAGE     ]

        [TARGET]

But it fails when the important content is near an edge.

A better resizer lets the user:

drag the image
zoom
reposition
preview output

Now the app is not just calculating dimensions.

It is helping the user preserve visual intent.

Safe areas complicate things further

A 1080×1920 canvas does not mean every pixel is equally useful.

Platform UI can overlap portions of vertical content:

captions
buttons
usernames
navigation
device chrome

So a more advanced resizer can visualize a "safe" region where important text and logos should stay.

This is not strictly part of image resizing.

It is part of platform-aware composition.

Multi-output changes the architecture

Generating one output can be synchronous and simple.

Generating 20+ outputs changes the UX.

The user now expects:

progress
predictable filenames
grouped results
one download
consistent crop rules

A filename scheme might look like:

campaign-instagram-portrait.jpg
campaign-linkedin-post.jpg
campaign-tiktok-vertical.jpg

Instead of making the user download each file individually, bundle them.

That is why ZIP export becomes a workflow feature, not a convenience.

How I think about the pipeline

A clean pipeline can look like:

Source image
    ↓
Decode once
    ↓
For each selected preset:
    - calculate scale
    - apply crop position
    - draw to canvas
    - export blob
    ↓
Package outputs
    ↓
Download ZIP

The key idea is to avoid redoing unnecessary work.

Decode once.

Reuse source state.

Generate targets from a shared transformation model.

Quality settings matter too

Different social assets have different needs.

A photographic post can tolerate lossy compression.

A graphic with small text may need a higher quality setting.

The resizer should avoid making destructive choices invisible.

Users should understand that smaller output files can trade away image quality.

I built this because the manual workflow is ridiculous

The real-world process often looks like:

Open Canva/Figma/Photoshop
Duplicate canvas
Resize
Fix crop
Export
Repeat
Repeat
Repeat

The creative decision was already made.

The remaining work is mechanical.

That is exactly the kind of task software should compress.

I built a version of this workflow into the BatchSet Social Media Resizer.

It currently focuses on turning one source image into platform-specific outputs without forcing the user to rebuild the design manually.

You can also see the broader marketing workflow here:

👉 BatchSet for Marketers

A useful product principle

When a user repeats the same transformation with different parameters, do not just build a faster single-action tool.

Ask whether the product should understand the set of outputs.

That is the difference between:

"resize image"

and:

"prepare this campaign for every channel"

The second framing produces a much more useful product.

Final thought

A social media resizer is a good example of how simple utilities hide interesting engineering problems.

The pixel math is easy.

The real work is in:

aspect-ratio behavior
crop control
preset maintenance
output naming
batch generation
safe-area UX
download packaging

That is where a small tool becomes a real workflow.

Next.js Image Optimization Starts Before

Muhaymin Bin Mehmood — Mon, 07 Sep 2026 14:00:00 +0000

Next.js gives us a powerful <Image /> component.

That is good.

But it can create a false sense that image optimization is now "handled."

It is not.

The component helps with delivery.

Your source-asset workflow still matters.

If your repository, CMS, or product catalog contains chaotic 6000px images with inconsistent crops and random filenames, <Image /> cannot turn that into a clean content pipeline by itself.

Layer 1: Source preparation

Before an image reaches your application, ask:

Is this source much larger than necessary?
Is the crop correct?
Is transparency needed?
Does the filename make sense?
Is the format appropriate?
Is this one asset or should there be multiple intentional variants?

This is content preparation, not framework behavior.

For a hero image, you may intentionally keep a large source.

For a small card icon, a huge photographic source makes no sense.

Layer 2: Correct component usage

A basic Next.js example:

import Image from "next/image";

export default function ProductCard({ product }) {
  return (
    <Image
      src={product.image}
      alt={product.name}
      width={640}
      height={640}
    />
  );
}

The important part is not just using <Image />.

The layout needs correct dimensions and the browser needs enough information to choose an appropriate resource.

For responsive layouts, the sizes prop matters.

<Image
  src={product.image}
  alt={product.name}
  fill
  sizes="(max-width: 768px) 50vw, 25vw"
/>

Without accurate sizing information, the browser may choose a larger image candidate than necessary.

Layer 3: Asset consistency

This is where teams lose time.

Suppose a product category contains:

shirt_01.JPG
shirt-2-final.png
IMG_9833.jpeg
newnewshirt.webp

The framework can render them.

But the content system is messy.

A better pipeline produces predictable names:

shirt-black-front.webp
shirt-black-back.webp
shirt-blue-front.webp
shirt-blue-back.webp

Predictability matters when you later:

generate feeds
build product imports
match SKUs
automate updates
debug broken references

Optimization is also organization.

Layer 4: Batch work belongs outside the component

If 300 source images need the same conversion, do not solve that inside React component logic.

Do it once before deployment or upload.

A batch preparation flow can be:

Raw assets
   ↓
Resize / crop
   ↓
Convert format
   ↓
Compress
   ↓
Validate naming
   ↓
Publish

This makes your app consume cleaner inputs.

For manual batches, I use the BatchSet Bulk Image Converter, which I built specifically because processing image collections one file at a time is painful.

For a fully automated production system, you may eventually move this pipeline into CI, a media service, or your CMS.

The principle is the same.

Layer 5: Do not preload everything

Another common mistake is treating every image as high priority.

If everything is important, nothing is important.

Above-the-fold hero imagery may deserve early loading.

Images far below the fold generally do not.

Your application should reflect actual visual priority.

Avoid turning every card into:

<Image priority ... />

just because it seems faster in one local test.

Layer 6: Measure with real content

Placeholder images lie.

A page tested with six tiny sample assets can behave very differently after the marketing team uploads the real catalog.

Performance testing should include realistic:

file dimensions
file sizes
image counts
device widths
network conditions

This is especially important for e-commerce grids.

Twenty optimized images can still create a meaningful transfer and rendering cost.

A workflow I recommend

Before content enters the app

Remove obviously oversized sources.
Normalize crop/aspect ratio when design requires it.
Convert to an appropriate modern format.
Apply sensible compression.
Use predictable filenames.

Inside Next.js

Use <Image /> correctly.
Provide correct dimensions or fill.
Configure sizes.
Prioritize only genuinely important images.
Measure real pages.

After deployment

Check Core Web Vitals.
Inspect the largest image requests.
Look for oversized resource selection.
Revisit the source pipeline if the same problem repeats.

Why this separation matters

Developers like solving everything in code.

But some performance problems are really content operations problems.

If your organization repeatedly uploads enormous, incorrectly cropped assets, adding more frontend logic may only hide the issue.

Fixing the input workflow can be simpler.

I collected the browser-based image preparation tools I am building here:

👉 BatchSet Image Tools

And for performance-focused use cases:

👉 BatchSet for SEO

Final thought

Next.js can optimize image delivery.

It cannot decide what your asset pipeline should be.

The strongest setup combines:

clean source assets
+
correct Next.js implementation
+
real performance measurement

That is the difference between using an image component and having an image strategy.

WebP vs AVIF in 2026: Stop Asking Which Is Better

Muhaymin Bin Mehmood — Sun, 06 Sep 2026 14:00:00 +0000

"WebP or AVIF?"

It sounds like a simple technical question.

It usually is not.

The answer depends on what you are optimizing for:

smallest possible file size
encoding speed
browser coverage
workflow simplicity
image type
quality requirements
CMS support
operational complexity

So instead of asking which format is universally "better," I prefer a more useful question:

Which format produces the best result for this website and this workflow?

Why WebP remains practical

WebP has become a very comfortable format for modern web workflows.

It is useful because it can handle:

photographic images
lossy compression
lossless compression
transparency

For many teams, WebP's biggest advantage is not a benchmark result.

It is operational maturity.

The tools are everywhere.

CMS support is common.

Developers understand it.

Design teams have seen it.

A WebP workflow is relatively easy to explain and maintain.

Why AVIF is attractive

AVIF can produce extremely efficient files, especially for certain photographic content.

If your priority is squeezing more bytes out of large image-heavy pages, it deserves testing.

But smaller output does not automatically mean the total workflow is better.

You should also consider:

encoding time
tooling
fallback behavior
how your CMS handles it
whether non-technical teammates can work with the format
whether your image pipeline supports it consistently

A technically superior file can create an operationally inferior system.

Use real images, not one benchmark

This is the most important part.

Do not take a single sample image and build a format policy around it.

Your production library may contain:

faces
screenshots
gradients
product photos
text-heavy graphics
transparent logos
dark scenes
noisy photographs

Different content compresses differently.

A useful test set should represent your actual site.

For example:

sample/
  product-white-background.jpg
  product-text-label.jpg
  dark-photo.jpg
  screenshot.png
  transparent-logo.png
  gradient-banner.png

Then export each through the candidate formats and compare:

file size
visible artifacts
decode behavior
page-level performance
workflow complexity

Avoid the "smallest file wins" trap

Imagine this result:

JPEG: 310 KB
WebP: 190 KB
AVIF: 155 KB

It is tempting to declare AVIF the winner.

But ask what happens next.

If AVIF requires a more complicated build step, slower generation, special handling in your CMS, and extra support burden, the 35 KB difference may not matter.

On a massive image catalog it might matter a lot.

On a small marketing site it may not.

Performance decisions should be proportional to the problem.

The boring answer is often the correct one

For many sites, a sensible policy can be:

Use modern formats.
Resize images properly.
Do not ship giant originals.
Compress reasonably.
Measure real pages.

This is less exciting than arguing about codecs.

It is also more likely to improve the site.

A 4000px AVIF displayed at 400px can still be a bad decision.

An appropriately sized WebP may beat it in the only metric users care about:

How quickly the useful page becomes visible.

What I use for BatchSet workflows

When I am preparing images for common web use, I often start with WebP because the workflow is straightforward.

For more aggressive optimization, AVIF becomes a candidate worth testing.

The important part is that I do not want format selection to become a manual one-file process.

That is why I built bulk conversion into BatchSet and collected the performance-oriented workflows under BatchSet for SEO.

Those links are to a product I build, so consider this the transparent "tool I use" section.

A simple decision framework

Choose WebP first when:

you want a broadly practical modern format
your team needs a simple workflow
your CMS supports it cleanly
you want transparency support
you need easy batch conversion

Test AVIF when:

image transfer size is a major bottleneck
your stack handles it well
you have large image-heavy pages
you can automate generation
you are willing to validate quality across browsers and assets

Keep PNG when:

you need lossless graphics and your workflow requires it
transparency and exact pixel behavior matter
the file is small enough that conversion adds no meaningful value

Keep JPEG when:

compatibility or external workflow constraints require it
the source is already well optimized
converting creates no meaningful improvement

Measure the page, not just the image

This is the part developers often skip.

You can save 50 KB on an image and still have a slow page because of:

blocking JavaScript
render delays
font loading
third-party scripts
poor caching
oversized DOM
slow backend responses

Image format is one lever.

It is not the entire performance strategy.

Final thought

WebP vs AVIF is not a championship fight.

They are tools.

The correct format is the one that gives you the best balance of:

quality + size + compatibility + maintainability

for your actual project.

Test representative files.

Automate the winning workflow.

Then spend your remaining performance budget on the problems your users can actually feel.

If you want a browser-based place to experiment with image formats, you can use BatchSet's Image Converter.

Your Image Converter Probably Doesn't Need Your Image on a Server

Muhaymin Bin Mehmood — Sat, 05 Sep 2026 14:00:00 +0000

Most online file tools follow the same architecture:

Choose file
   ↓
Upload file
   ↓
Server processes it
   ↓
Server stores a temporary result
   ↓
Download result

That architecture is valid.

But for many image operations, it is not always necessary.

Modern browsers can decode, transform, and export common image formats locally. That means some tools can work without sending the original image to a backend at all.

This changes the architecture in an interesting way.

Choose file
   ↓
Browser reads it locally
   ↓
Browser transforms it
   ↓
Download result

No upload step.

For the right use case, that is a meaningful improvement.

Why client-side processing is attractive

1. Privacy

If the file does not need to leave the device, you remove an entire category of questions:

Where is the file stored?
For how long?
Is it logged?
Is it copied to object storage?
Is a third-party processor involved?
Is cleanup actually happening?

Client-side processing does not magically make an application secure, but it can reduce the amount of sensitive data that needs to cross the network.

For personal photos, unreleased marketing assets, client work, screenshots, and internal images, that matters.

2. Less upload latency

Uploading a 2 MB file is usually fine.

Uploading 100 files is a different experience.

If the transformation can happen locally, the user does not need to wait for:

upload → server queue → processing → download

before seeing a result.

Network conditions become less important.

3. Lower backend cost

If your backend is doing CPU-heavy conversion for every free user, infrastructure cost scales directly with usage.

Moving suitable work to the client can reduce:

CPU usage
temporary storage
bandwidth
queue pressure

This is especially interesting for free utility tools where the server cost of a single action can be larger than the revenue generated by that user.

4. Better offline potential

A browser tool that does not depend on a processing API can sometimes continue working even when connectivity is limited, depending on how the app itself is delivered and cached.

That is a very different user experience from a server-only tool.

What can the browser actually do?

For common formats, browser APIs can already handle a surprising amount.

Typical building blocks include:

File
Blob
FileReader
createImageBitmap()
<canvas>
OffscreenCanvas
Web Workers

A simplified flow can look like:

const file = input.files[0];

const bitmap = await createImageBitmap(file);

const canvas = document.createElement("canvas");
canvas.width = bitmap.width;
canvas.height = bitmap.height;

const ctx = canvas.getContext("2d");
ctx.drawImage(bitmap, 0, 0);

const result = await new Promise(resolve => {
  canvas.toBlob(resolve, "image/webp", 0.82);
});

This is intentionally minimal, but the important idea is that the image can be decoded and re-encoded without a traditional upload-processing-download cycle.

The hard part is not the demo

A one-file demo is easy.

Production behavior is harder.

You have to think about:

memory usage
large dimensions
EXIF orientation
transparent images
browser support
output quality
cancellation
progress reporting
multiple files
UI responsiveness

If a user drops 200 high-resolution photos into the browser and you decode everything simultaneously, you can easily destroy the tab.

So "client-side" does not mean "process everything at once."

Controlled concurrency matters

A safer batch architecture uses a queue.

Instead of:

await Promise.all(files.map(processImage));

you may want a controlled number of active jobs.

Conceptually:

200 files waiting

Worker 1 → image
Worker 2 → image
Worker 3 → image
Worker 4 → image

Complete one → take next

The correct concurrency depends on workload and device capabilities.

The goal is not maximum parallelism.

The goal is useful throughput without making the browser unusable.

When a server is still the better choice

Client-side processing is not a religion.

There are many cases where a backend is appropriate or required:

unsupported codecs
extremely large files
expensive AI models
server-side persistence
shared team workflows
centralized processing rules
conversions that require native libraries
jobs that must continue after the tab closes

The architecture should follow the job.

A product-design consequence

Once basic image conversion can happen locally, the product can make a stronger promise:

"Your common image conversions do not need to be uploaded for processing."

That was one of the design goals behind the basic image workflows I am building in BatchSet.

You can try the Image Converter or the Bulk Image Converter.

I am mentioning it because it is the real product where I have been exploring this architecture, not because every transformation inside every application should be client-side.

The broader lesson

Before adding another API endpoint, queue, storage bucket, and cleanup job, ask one question:

Does the server actually need this file?

Sometimes the answer is yes.

Sometimes the browser is already powerful enough to do the job closer to the user.

And when the answer is "the browser can do it," you may get privacy, speed, and infrastructure benefits at the same time.

Your Shopify Store Is Fast Until the Product Images Arrive: A Practical WebP Workflow

Muhaymin Bin Mehmood — Fri, 04 Sep 2026 14:00:00 +0000

A storefront can feel fast during development and suddenly become sluggish the moment the real product catalog is added.

The code may be fine.

The theme may be fine.

The server may be fine.

The problem is often much simpler: the browser is downloading far more image data than the page actually needs.

If you manage Shopify, WooCommerce, Daraz, or any image-heavy catalog, image optimization is not just a "convert JPG to WebP" task. It is a repeatable workflow.

This is the workflow I use.

Step 1: Start with display size, not file format

Imagine a product grid where every card displays an image at roughly 500px wide.

Now imagine the source files are 4000px wide.

Even if those 4000px images are compressed, the browser is still receiving far more image data than necessary.

Before changing formats, ask:

What size is the image actually displayed at?
Do I need a large zoom image?
Is the same source used for thumbnails and product detail pages?
Can I generate more appropriate variants?

The best optimization is often not shipping unnecessary pixels in the first place.

Step 2: Choose a modern output format

For many web storefronts, WebP is a strong default because it can significantly reduce file size while keeping visual quality suitable for product photography.

That does not mean WebP wins every situation.

PNG can still make sense for certain graphics and transparency-heavy assets.

JPEG is still widely compatible.

AVIF can achieve excellent compression, but your workflow, tooling, and quality requirements should decide whether the additional complexity is worth it.

The practical rule is:

Test your real catalog images instead of choosing a format from a benchmark headline.

Take a sample of:

bright product photos
dark product photos
images with text
transparent assets
highly detailed products

Then compare visual quality and output size.

Step 3: Stop converting one file at a time

This is where image optimization turns into an operational problem.

Converting 3 files manually is easy.

Converting 800 product images manually is not.

If every file needs the same transformation, the settings belong at the batch level.

A useful batch process looks like this:

Select product images
        ↓
Choose output format
        ↓
Set shared quality / resize rules
        ↓
Process the batch
        ↓
Download the results together

That is much better than:

Open file
Convert
Download
Rename
Repeat 799 times

I built a browser-based version of this workflow into BatchSet's Bulk Image Converter.

The goal is not to make a single conversion impressive.

The goal is to remove the repeated work.

Step 4: Preserve naming discipline

Optimization can create a second problem: chaotic filenames.

If your original files are:

sku-1001-front.jpg
sku-1001-side.jpg
sku-1002-front.jpg

your optimized versions should remain predictable.

For example:

sku-1001-front.webp
sku-1001-side.webp
sku-1002-front.webp

Avoid workflows that turn a clean catalog into:

download-1.webp
download-2.webp
final-final-2.webp

This matters later when you:

update products
debug missing images
match assets to SKUs
build import spreadsheets
hand the catalog to another team member

File naming is part of the image pipeline.

Step 5: Do not optimize blindly

A smaller file is not automatically a better file.

Compression can damage:

small text
fabric detail
jewelry edges
product labels
fine textures

For e-commerce, image quality affects trust.

The target is not "smallest possible file."

The target is:

small enough to load quickly while still looking good enough to sell the product.

That is why I prefer a sample-based process:

Pick representative images.
Test a few quality levels.
Inspect them at real storefront size.
Choose the lowest acceptable setting.
Apply it to the full batch.

Step 6: Think beyond conversion

A complete product-image workflow may include:

resizing
cropping
background cleanup
format conversion
compression
naming
bulk export
marketplace-specific dimensions

That is why I think "image converter" is often too narrow a way to describe the real problem.

The real problem is catalog preparation.

If your daily work involves Shopify, Daraz, Amazon, or WooCommerce product images, I put the e-commerce-focused BatchSet tools together here:

👉 BatchSet for E-Commerce

A simple checklist

Before uploading a new product catalog, I would check:

[ ] Images are not massively larger than their display size
[ ] Output format makes sense for the asset
[ ] Compression has been visually tested
[ ] Filenames remain predictable
[ ] Similar files are processed as a batch
[ ] Important transparent assets remain transparent
[ ] Product details are still sharp enough to inspect

Final thought

Image optimization is usually presented as a format choice.

It is really a workflow design problem.

If you optimize one image perfectly but the process is too slow to repeat across the other 2,000 files in your catalog, the solution does not scale.

A good workflow should be fast enough that optimization becomes part of publishing, not a special cleanup project you postpone for six months.

If you want to try the workflow I am building around this problem:

I am building BatchSet, so feedback from people managing real product catalogs is especially useful.

Why does bulk image conversion break with remote URLs? CORS.

Muhaymin Bin Mehmood — Thu, 03 Sep 2026 13:59:55 +0000

Muhaymin Bin Mehmood

Sep 1

Bulk-Converting Image URLs from CSV: Why CORS Breaks the Browser-Only Approach

#javascript #webdev #ecommerce #architecture

6 min read

Bulk-Converting Image URLs from CSV: Why CORS Breaks the Browser-Only Approach

Muhaymin Bin Mehmood — Tue, 01 Sep 2026 14:00:00 +0000

I like browser-only image processing.

For local files, the architecture can be beautifully simple:

user's disk
    ↓
browser
    ↓
decode
    ↓
convert
    ↓
download

No upload.

No temporary server storage.

No queue worker.

Then someone asks:

Can I upload a CSV containing 500 product image URLs and convert all of those too?

At first, it sounds like the same feature with a different input source.

It isn't.

The moment the images live on arbitrary remote domains, your browser runs into the web's cross-origin security model.

Local files and remote URLs are different trust boundaries

With a local file input:

<input
  type="file"
  accept="image/*"
/>

the user explicitly gives your page access to selected files.

You can create object URLs:

const url =
  URL.createObjectURL(file);

decode the asset, draw it, and process it.

With a remote URL:

https://merchant-cdn.example/product-123.jpg

your page does not automatically have permission to fetch and read that resource however it wants.

That is where CORS enters the architecture.

What happens with `fetch()`

Suppose a CSV contains:

sku,image_url
A-100,https://cdn-a.example/a.jpg
A-101,https://cdn-b.example/b.jpg

Your first attempt might be:

const response =
  await fetch(imageUrl);

const blob =
  await response.blob();

This works only when the target server's cross-origin policy allows the request.

If the server does not send suitable CORS headers, the browser blocks JavaScript from reading the response.

That is intentional.

Why browsers enforce this

Without same-origin restrictions, any random site you visit could potentially try to read resources from other services where your browser has credentials or access.

The same-origin policy is one of the web's fundamental security boundaries.

CORS is a controlled mechanism that lets a server say:

I explicitly allow this other origin to access my resource.

If the image server does not grant that permission, your frontend cannot simply override it.

The Canvas version of the problem

There is another variation.

Sometimes an external image can visually appear in a page, but drawing it to Canvas and attempting to read/export the Canvas causes a security error.

Conceptually:

remote image
    ↓
Canvas draws it
    ↓
Canvas becomes tainted
    ↓
toBlob / toDataURL blocked

MDN explains this in:

Use cross-origin images in a canvas

This matters for image converters because export normally requires access to the resulting pixel data.

Why `mode: "no-cors"` does not solve it

A common Stack Overflow-style suggestion is:

fetch(url, {
  mode: "no-cors"
});

That does not give you a readable image response.

It generally produces an opaque response that JavaScript cannot inspect like a normal cross-origin resource.

So this does not magically turn:

CORS denied

into:

full image bytes available

If your application needs the bytes, the remote server must allow the request or you need another architecture.

Architecture 1: fully browser-side when sources support CORS

The ideal case:

CSV
 ↓
browser parses rows
 ↓
fetch image URL
 ↓
remote CDN allows CORS
 ↓
Blob
 ↓
decode / convert
 ↓
download

This is excellent when you control the source CDN.

For example, your own infrastructure can return:

Access-Control-Allow-Origin: https://yourapp.example

or another appropriate policy.

Architecture 2: server-side fetch layer

For arbitrary public product-image URLs, you cannot assume every server has a browser-friendly CORS policy.

A common architecture becomes:

CSV
 ↓
browser parses / previews
 ↓
send URL job
 ↓
your backend fetches remote image
 ↓
validate response
 ↓
convert / normalize
 ↓
return output

The server is not restricted by browser CORS in the same way because CORS is primarily a browser-enforced policy.

But now you have new security problems.

Server-side URL fetching creates SSRF risk

Do not build:

app.post("/fetch-image", async (req, res) => {
  const response =
    await fetch(req.body.url);

  res.send(
    await response.arrayBuffer()
  );
});

and call it finished.

If users can make your server fetch arbitrary URLs, you may accidentally create a Server-Side Request Forgery surface.

An attacker could try:

http://localhost:...
http://127.0.0.1:...
http://169.254.169.254/...
private network hosts
redirect chains
unexpected protocols

A production fetcher needs controls.

A safer remote-fetch checklist

At minimum, consider:

allow http/https only
resolve DNS carefully
block private/internal IP ranges
limit redirects
re-validate every redirect target
limit response size
limit time
validate content type
validate actual file signature
rate limit users
avoid forwarding user cookies
avoid forwarding internal credentials

"Proxy the URL through the backend" sounds easy.

A secure fetch service is not trivial.

Validate actual image content

Do not trust only:

Content-Type: image/jpeg

The server may be wrong or malicious.

You should enforce:

maximum bytes
expected media types
decodable image content
maximum dimensions
reasonable processing limits

A file that claims to be an image can still be dangerous from a resource-exhaustion perspective.

Parse the spreadsheet in the browser first

Even when remote fetching requires a backend, you can still keep useful work client-side.

For example:

Excel / CSV
     ↓
browser parses file
     ↓
show columns
     ↓
detect image URL column
     ↓
validate obvious row errors
     ↓
preview first rows
     ↓
user confirms job
     ↓
server processes URLs

This is better UX than immediately uploading the spreadsheet and making the user guess what will happen.

It also reduces unnecessary server jobs.

Example CSV workflow

Suppose we support:

sku,image_url,format,quality
SKU-001,https://cdn.example/1.jpg,webp,82
SKU-002,https://cdn.example/2.png,webp,82
SKU-003,https://other.example/3.jpg,jpg,90

The browser can validate:

function validateRow(row) {
  const errors = [];

  try {
    const url =
      new URL(row.image_url);

    if (
      !["http:", "https:"]
        .includes(url.protocol)
    ) {
      errors.push(
        "Unsupported URL protocol"
      );
    }
  } catch {
    errors.push(
      "Invalid image URL"
    );
  }

  if (
    !["webp", "jpg", "png"]
      .includes(row.format)
  ) {
    errors.push(
      "Unsupported format"
    );
  }

  return errors;
}

That catches obvious bad data before the remote job starts.

Queueing matters at 500 URLs

Do not launch:

await Promise.all(
  urls.map(processUrl)
);

against 500 large images unless your system is explicitly designed for that concurrency.

A queue gives you control.

async function runPool(
  items,
  worker,
  concurrency = 5
) {
  let index = 0;

  async function run() {
    while (true) {
      const current =
        index++;

      if (
        current >=
        items.length
      ) {
        return;
      }

      await worker(
        items[current]
      );
    }
  }

  await Promise.all(
    Array.from(
      { length: concurrency },
      run
    )
  );
}

Now you can tune:

network concurrency
CPU conversion concurrency
memory usage
provider rate limits

separately if needed.

Failure reporting is part of the feature

In a batch of 500 URLs, some will fail.

Reasons include:

404
timeout
unsupported format
CORS
server rejection
image too large
corrupt file
DNS failure

Do not make the entire job fail because row 317 is bad.

Return a result report:

sku,status,error
SKU-001,success,
SKU-002,success,
SKU-003,failed,HTTP 404

The user needs to know what to fix.

Why the browser-only rule should not become ideology

"Everything should happen locally" is a useful design preference.

It should not become a fake claim when the problem no longer fits.

For local files, browser-only conversion is a great architecture.

For arbitrary remote URLs, the browser's security boundary changes the problem.

The correct design can be hybrid:

Local files:
browser

Spreadsheet parsing:
browser

Remote URL fetch:
server when required

Preview:
browser

Final download:
browser

That is not a failure of client-side architecture.

It is a consequence of the web security model.

This is exactly why my Excel/CSV workflow differs from normal BatchSet conversion

BatchSet's ordinary local-file conversion can process files in the browser.

But the Excel/CSV Image Converter has to deal with remote URLs that may live on arbitrary CDNs.

So the workflow is intentionally different:

spreadsheet
→ preview
→ account-backed remote batch
→ fetch images
→ convert
→ package output

The live tool explains this distinction rather than pretending remote URL ingestion is identical to local processing.

If you already have a product catalog in Excel or CSV and want to test the workflow:

Open BatchSet's Excel/CSV Image Converter

Product insight: architecture can become a marketing advantage

Developers notice when a product explains its boundaries.

Instead of saying:

100% browser-only!

for every feature, a more credible message is:

Local files stay local.

Remote URL jobs use a server fetch layer
when the browser cannot legally read
the remote source.

That is both more accurate and more useful.

Users do not need slogans.

They need to know where their data goes.

Final takeaway

Bulk image conversion from a spreadsheet is not just:

loop over URLs
→ convert

The moment your source images live on other domains, your architecture must account for:

CORS
Canvas tainting
safe remote fetching
SSRF
timeouts
validation
concurrency
partial failures

For local files, the browser can be the entire processing engine.

For arbitrary remote URLs, a hybrid client/server pipeline is often the more honest and robust design.