DEV Community: Muhaymin Bin Mehmood

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.

EAN-13 and UPC-A Check Digits Explained: Build a Barcode Validator in JavaScript

Muhaymin Bin Mehmood — Mon, 31 Aug 2026 14:00:00 +0000

A barcode can look perfectly valid and still encode an invalid number.

That is because retail barcode formats such as EAN-13 and UPC-A do more than render black bars.

They also include a check digit.

The check digit helps detect common mistakes in the numeric identifier.

Once you understand the algorithm, you can build a validator in a few lines of JavaScript.

What a check digit does

A check digit does not encrypt the number.

It does not prove that a product exists.

It does not tell you who owns the barcode.

It is a small integrity check.

GS1 describes the final digit of a barcode number as a check digit used to make sure the number is correctly composed.

Official reference:

GS1 Check Digit Calculator

EAN-13 structure

EAN-13 contains 13 digits.

Conceptually:

12 data digits
+ 1 check digit
= 13 digits

Example:

4006381333931

Here:

400638133393

is the first 12 digits.

The final:

is the check digit.

Let's calculate it.

EAN-13 check digit algorithm

Take the first 12 digits.

Starting from the left:

multiply digits in odd positions by 1
multiply digits in even positions by 3
add the results
find what digit must be added to reach the next multiple of 10

Using:

4 0 0 6 3 8 1 3 3 3 9 3

Weights:

1 3 1 3 1 3 1 3 1 3 1 3

Multiply:

4×1 = 4
0×3 = 0
0×1 = 0
6×3 = 18
3×1 = 3
8×3 = 24
1×1 = 1
3×3 = 9
3×1 = 3
3×3 = 9
9×1 = 9
3×3 = 9

Sum:

4 + 0 + 0 + 18
+ 3 + 24 + 1 + 9
+ 3 + 9 + 9 + 9
= 89

We need the next multiple of 10:

So:

90 - 89 = 1

Check digit:

Full EAN-13:

4006381333931

A clean JavaScript implementation

function ean13CheckDigit(
  first12
) {
  if (!/^\d{12}$/.test(first12)) {
    throw new Error(
      "EAN-13 payload must be 12 digits"
    );
  }

  const sum =
    [...first12]
      .map(Number)
      .reduce(
        (total, digit, index) => {
          const weight =
            index % 2 === 0
              ? 1
              : 3;

          return (
            total +
            digit * weight
          );
        },
        0
      );

  return (
    10 - (sum % 10)
  ) % 10;
}

Test it:

console.log(
  ean13CheckDigit(
    "400638133393"
  )
);

// 1

Generate a complete EAN-13 number

function completeEan13(first12) {
  const checkDigit =
    ean13CheckDigit(first12);

  return (
    first12 +
    checkDigit
  );
}

console.log(
  completeEan13(
    "400638133393"
  )
);

// 4006381333931

Validate an existing EAN-13

function isValidEan13(value) {
  if (!/^\d{13}$/.test(value)) {
    return false;
  }

  const payload =
    value.slice(0, 12);

  const expected =
    ean13CheckDigit(payload);

  const actual =
    Number(value[12]);

  return expected === actual;
}

Test:

console.log(
  isValidEan13(
    "4006381333931"
  )
);

// true

A more generic Mod-10 function

EAN/UPC families use related Mod-10 weighting logic.

You can write a generic helper:

function calculateGs1CheckDigit(
  payload
) {
  if (!/^\d+$/.test(payload)) {
    throw new Error(
      "Payload must contain digits only"
    );
  }

  const digits =
    [...payload]
      .map(Number)
      .reverse();

  const sum =
    digits.reduce(
      (total, digit, index) => {
        const weight =
          index % 2 === 0
            ? 3
            : 1;

        return (
          total +
          digit * weight
        );
      },
      0
    );

  return (
    10 - (sum % 10)
  ) % 10;
}

The reverse-first approach makes it easier to reason from the rightmost payload digit.

For EAN-13, pass the 12 data digits.

For UPC-A, pass the 11 data digits.

UPC-A example

UPC-A is commonly represented as:

11 data digits
+ 1 check digit
= 12 digits

So:

function completeUpcA(first11) {
  if (!/^\d{11}$/.test(first11)) {
    throw new Error(
      "UPC-A payload must be 11 digits"
    );
  }

  return (
    first11 +
    calculateGs1CheckDigit(
      first11
    )
  );
}

Validation:

function isValidUpcA(value) {
  if (!/^\d{12}$/.test(value)) {
    return false;
  }

  const payload =
    value.slice(0, 11);

  const expected =
    calculateGs1CheckDigit(
      payload
    );

  return (
    expected ===
    Number(value[11])
  );
}

Why modulo 10?

The check digit is chosen so the weighted total plus the check digit ends on a multiple of 10.

If:

sum % 10 = 0

then the check digit is:

That is why the formula is usually written:

(10 - (sum % 10)) % 10

The second % 10 handles the case where the sum is already divisible by 10.

Without it:

10 - 0 = 10

which is not a valid single digit.

Check digits are validation, not uniqueness

This is an important distinction.

Suppose your function says:

isValidEan13("...") === true

That only means:

the number passes the mathematical check-digit rule.

It does not automatically mean:

the number was licensed correctly
the product exists
the manufacturer matches
the identifier is currently assigned
a marketplace will accept it

For real GS1 identity verification, use appropriate GS1 services and rules.

Barcode data vs barcode image

Another common confusion:

valid number
≠
valid barcode image

Once the data is correct, you still have to render the symbol correctly.

That includes things such as:

bar pattern
quiet zones
dimensions
readable contrast
correct human-readable text
print scaling

So there are really two layers:

Layer 1:
identifier validation

Layer 2:
barcode rendering

This article is primarily about Layer 1.

Why this matters in e-commerce tooling

If you process hundreds of products from a spreadsheet, it is much better to catch invalid identifiers before creating hundreds of barcode images.

A useful workflow:

CSV / Excel
    ↓
validate values
    ↓
calculate missing check digits
    ↓
flag invalid rows
    ↓
render barcode images
    ↓
download

Validation belongs before rendering.

Batch generation adds product-level complexity

Generating one barcode is easy.

Generating 500 introduces new concerns:

filenames
duplicate values
invalid rows
format selection
progress
ZIP packaging
spreadsheet mapping
error reporting

That is why a barcode generator quickly becomes a workflow tool.

I built these kinds of operational flows into BatchSet's Barcode Generator.

The current tool supports formats including:

EAN-13
UPC-A
EAN-8
UPC-E
Code 128

and handles check digits for the relevant retail formats exposed in the interface.

If you need the actual scannable output rather than only the checksum code:

Generate a barcode with BatchSet

Useful test cases

Do not test only valid inputs.

const cases = [
  "",
  "123",
  "abcdefghijkl",
  "400638133393",
  "000000000000",
  "999999999999"
];

for (const value of cases) {
  try {
    console.log(
      value,
      ean13CheckDigit(value)
    );
  } catch (error) {
    console.log(
      value,
      error.message
    );
  }
}

Also test validation with:

correct check digit
incorrect check digit
leading zeros
non-digit input
too few digits
too many digits

Leading zeros are especially important because barcode identifiers are strings, not ordinary numbers.

Do not do this:

Number("012345678901")

if preserving the exact identifier matters.

Keep the value as a string.

Final takeaway

A retail barcode is not just black lines.

Before you render anything, validate the identifier.

For EAN-13 and UPC-A, the check-digit algorithm is small enough to understand and implement directly:

weighted sum
→ modulo 10
→ final check digit

That little validation step can prevent a surprising amount of bad data from moving deeper into an e-commerce or inventory workflow.

SVG PNG looks simple. It isn’t. Here’s what actually happens inside the browser. 👇

Muhaymin Bin Mehmood — Mon, 31 Aug 2026 01:58:17 +0000

Muhaymin Bin Mehmood

Aug 27

SVG to PNG in the Browser: Rasterization, Transparency, Fonts, and a Production-Safe JavaScript Pipeline

#javascript #webdev #svg #frontend

7 min read

PDF to JPG/PNG in the Browser: Rendering Pages with PDF.js Without Uploading the Document

Muhaymin Bin Mehmood — Sun, 30 Aug 2026 14:00:00 +0000

"Convert this PDF to PNG" sounds like an image conversion task.

But a PDF page is not necessarily an image.

It can contain:

vector text
fonts
shapes
embedded images
clipping paths
transparency
annotations
multiple layers of drawing instructions

So a PDF → PNG workflow usually has to render the page, not simply extract an image from it.

That difference explains almost everything about how browser-side PDF-to-image tools work.

Mental model: render first, encode second

The pipeline is:

PDF bytes
   ↓
Parse document
   ↓
Load page
   ↓
Create viewport
   ↓
Render page to Canvas
   ↓
Encode Canvas as JPG / PNG
   ↓
Download

Mozilla's PDF.js is a web-standards-based PDF parsing and rendering platform.

Its examples show exactly this kind of browser rendering workflow.

Load a PDF

Assume the user selects a local PDF:

<input
  id="pdfInput"
  type="file"
  accept="application/pdf"
/>

Read the bytes:

const file =
  pdfInput.files[0];

const arrayBuffer =
  await file.arrayBuffer();

Then load the document with PDF.js:

const loadingTask =
  pdfjsLib.getDocument({
    data: arrayBuffer
  });

const pdf =
  await loadingTask.promise;

console.log(
  pdf.numPages
);

Nothing has been uploaded.

The PDF bytes can stay inside the browser.

Render one page

Let's render page 1.

const page =
  await pdf.getPage(1);

PDF.js uses a viewport to determine rendering dimensions.

const viewport =
  page.getViewport({
    scale: 2
  });

Create a Canvas:

const canvas =
  document.createElement(
    "canvas"
  );

const ctx =
  canvas.getContext("2d");

canvas.width =
  Math.ceil(viewport.width);

canvas.height =
  Math.ceil(viewport.height);

Then render:

await page.render({
  canvasContext: ctx,
  viewport
}).promise;

At this point, the composed PDF page has become pixels in a Canvas.

Why `scale` matters

Suppose the PDF page's base viewport is approximately:

612 × 792

At:

scale: 1

you render around:

612 × 792

At:

scale: 2

you render around:

1224 × 1584

At:

scale: 3

you render around:

1836 × 2376

Higher scale means:

more pixels
potentially sharper output
larger files
more memory usage
more rendering time

So "quality" is not only an encoder setting.

For a PDF page, render resolution itself is a major quality decision.

Export as PNG

Once the page is on Canvas:

const blob =
  await new Promise(
    (resolve, reject) => {
      canvas.toBlob(
        (result) => {
          result
            ? resolve(result)
            : reject(
                new Error(
                  "PNG encoding failed"
                )
              );
        },
        "image/png"
      );
    }
  );

PNG is useful when:

text must remain crisp
screenshots/diagrams dominate
transparency matters
lossless output is preferred

Export as JPEG

For JPEG:

const blob =
  await new Promise(
    (resolve, reject) => {
      canvas.toBlob(
        (result) => {
          result
            ? resolve(result)
            : reject(
                new Error(
                  "JPEG encoding failed"
                )
              );
        },
        "image/jpeg",
        0.9
      );
    }
  );

The third argument controls JPEG quality.

Example:

0.6 → smaller / more artifacts
0.8 → useful balance
0.9 → higher quality / larger

JPEG is often better for photo-heavy PDF pages.

Download the page

const url =
  URL.createObjectURL(blob);

const link =
  document.createElement("a");

link.href = url;
link.download = "page-1.png";
link.click();

URL.revokeObjectURL(url);

One page is easy.

The interesting engineering begins when the PDF has 100 pages.

Render a page range

Users rarely want to process every page blindly.

A simple range parser can start with input like:

1-3,7,10-12

Conceptually:

function parsePageRange(
  input,
  maxPages
) {
  const pages = new Set();

  for (
    const part
    of input.split(",")
  ) {
    const token =
      part.trim();

    if (!token) continue;

    if (token.includes("-")) {
      const [a, b] =
        token
          .split("-")
          .map(Number);

      for (
        let page = a;
        page <= b;
        page++
      ) {
        if (
          page >= 1 &&
          page <= maxPages
        ) {
          pages.add(page);
        }
      }
    } else {
      const page =
        Number(token);

      if (
        page >= 1 &&
        page <= maxPages
      ) {
        pages.add(page);
      }
    }
  }

  return [...pages]
    .sort((a, b) => a - b);
}

Then:

const selectedPages =
  parsePageRange(
    "1-3,7",
    pdf.numPages
  );

Do not render 100 pages simultaneously

This is the easiest way to turn a browser tab into a memory problem.

Imagine each rendered page becomes:

2000 × 2800

That is:

5.6 million pixels

Raw RGBA memory alone can be roughly:

5.6M × 4 bytes
≈ 22.4 MB

per canvas before counting PDF.js internals, encoded Blobs, JavaScript objects, and browser overhead.

Ten pages at once can become expensive quickly.

A better strategy is:

page
→ render
→ encode
→ store Blob / ZIP entry
→ release Canvas
→ next page

That limits peak memory.

Sequential renderer

async function renderPages(
  pdf,
  pages,
  scale = 2
) {
  const results = [];

  for (const pageNumber of pages) {
    const page =
      await pdf.getPage(
        pageNumber
      );

    const viewport =
      page.getViewport({
        scale
      });

    const canvas =
      document.createElement(
        "canvas"
      );

    canvas.width =
      Math.ceil(
        viewport.width
      );

    canvas.height =
      Math.ceil(
        viewport.height
      );

    const ctx =
      canvas.getContext("2d");

    await page.render({
      canvasContext: ctx,
      viewport
    }).promise;

    const blob =
      await new Promise(
        (resolve, reject) => {
          canvas.toBlob(
            (result) => {
              result
                ? resolve(result)
                : reject(
                    new Error(
                      "Encoding failed"
                    )
                  );
            },
            "image/png"
          );
        }
      );

    results.push({
      pageNumber,
      blob
    });

    canvas.width = 1;
    canvas.height = 1;

    page.cleanup?.();
  }

  return results;
}

This is not necessarily the fastest possible implementation.

It is deliberately conservative.

For a browser tool, predictable memory behavior is often more valuable than maximum concurrency.

PDF → Image is not image extraction

This distinction is worth repeating.

Suppose a PDF page contains:

logo.svg-like vectors
+ selectable text
+ a photograph
+ a table

Extracting the embedded photograph would give you only one asset.

Rendering the page gives you the complete visual composition.

That is why "PDF to PNG" normally means:

render the page into raster pixels.

Handling passwords and invalid PDFs

Production UX needs to account for:

encrypted PDFs
malformed files
zero-page edge cases
very large files
unsupported structures
rendering errors

Do not collapse all failures into:

Something went wrong

Useful errors are part of the product.

For example:

This PDF requires a password.

Page 17 could not be rendered.

The requested render size is too large for this browser.

Progress matters

A 70-page conversion should not feel frozen.

Useful progress:

Rendering page 23 of 70

or:

33%

Internally, the operation can report:

onProgress?.({
  completed: index + 1,
  total: pages.length
});

If the user understands that work is happening, they are much less likely to refresh the page.

ZIP download is the natural multi-page output

If you render:

page-001.png
page-002.png
page-003.png
...

asking the user to click 30 downloads is terrible UX.

The natural result is:

document-pages.zip

containing all outputs.

This is one reason a finished PDF-to-image tool needs more than a 20-line PDF.js demo.

The rendering API is only the engine.

The product still needs:

page selection
quality controls
format controls
naming
progress
ZIP packaging
memory management
download UX

Why local processing is useful for PDFs

PDFs are often more sensitive than ordinary images.

They may contain:

invoices
internal documents
contracts
presentations
reports
customer records

When a PDF-to-image workflow can run locally, the document does not need to be uploaded merely to render its pages.

That is one of the reasons I like browser-side PDF rendering.

For the straightforward "I need these PDF pages as JPG/PNG" use case, I added a dedicated local workflow to BatchSet.

It supports page selection, JPG/PNG output, quality controls, and ZIP download.

If you need the rendered pages rather than the rendering code:

Convert PDF to JPG/PNG with BatchSet

Final takeaway

A PDF page is a document surface, not simply an image file.

The practical browser pipeline is:

parse
→ load page
→ choose render scale
→ render to Canvas
→ encode JPG/PNG
→ package outputs

Once you understand that, the quality, memory, and performance trade-offs become much easier to reason about.

And if your goal is just to get the images, you can let the browser do the rendering without building the surrounding workflow yourself.

Cover vs Contain vs Stretch: The Image-Resizing Math Frontend Developers Should Understand

Muhaymin Bin Mehmood — Sat, 29 Aug 2026 14:00:00 +0000

You have a 1600 × 900 image.

You need to place it into a 1080 × 1350 Instagram-style canvas.

Three different tools give you three different results:

one crops the left and right edges
one adds empty space
one makes everything look unnaturally tall

None of those tools is necessarily broken.

They are applying different image fitting rules.

Frontend developers use these rules constantly through CSS properties such as object-fit, but the underlying math is simple enough that it is worth understanding directly.

Start with aspect ratio

Aspect ratio is:

width / height

For our source:

1600 / 900
= 1.777...

That is approximately:

16:9

For the target:

1080 / 1350
= 0.8

That is:

4:5

So we are trying to fit a wide image into a portrait box.

There is no way to do that while simultaneously:

showing every source pixel
filling every target pixel
preserving the original aspect ratio

You must sacrifice something.

That is the entire reason contain, cover, and stretch exist.

Contain

contain means:

Scale the image until the entire image fits inside the target.

The scale factor is:

containScale =
  min(
    targetWidth / sourceWidth,
    targetHeight / sourceHeight
  )

Using our values:

targetWidth / sourceWidth
= 1080 / 1600
= 0.675

targetHeight / sourceHeight
= 1350 / 900
= 1.5

Take the smaller value:

containScale = 0.675

The final image becomes:

1600 × 0.675 = 1080
900 × 0.675 = 607.5

So the rendered image is approximately:

1080 × 608

inside a:

1080 × 1350

canvas.

Result:

image fully visible
+ aspect ratio preserved
+ empty space remains

The vertical empty space is:

1350 - 608
= 742px

If centered:

371px top
371px bottom

Cover

cover means:

Scale the image until the entire target is filled.

The formula is:

coverScale =
  max(
    targetWidth / sourceWidth,
    targetHeight / sourceHeight
  )

We already calculated:

0.675
1.5

Take the larger value:

coverScale = 1.5

Now:

1600 × 1.5 = 2400
900 × 1.5 = 1350

The scaled image is:

2400 × 1350

inside a target of:

1080 × 1350

The target is completely filled.

But:

2400 - 1080
= 1320px

must be cropped horizontally.

If centered:

660px cropped from left
660px cropped from right

Result:

target fully filled
+ aspect ratio preserved
+ some source content removed

Stretch

Stretch means:

Ignore the source aspect ratio and force the image to exactly match the target.

So:

1600 × 900

becomes:

1080 × 1350

The horizontal scale is:

1080 / 1600
= 0.675

The vertical scale is:

1350 / 900
= 1.5

Those values are very different.

The result will be visibly distorted.

People become taller.

Circles become ovals.

Logos become malformed.

Stretch is useful in some generated textures or abstract cases, but it is rarely the right default for photography.

The three modes in one table

Mode	Preserves aspect ratio?	Shows all source content?	Fills target completely?
Contain	Yes	Yes	No
Cover	Yes	No	Yes
Stretch	No	Yes	Yes

This table explains most resizing UI.

JavaScript implementation

Let's implement the sizing calculations.

function containSize(
  sourceWidth,
  sourceHeight,
  targetWidth,
  targetHeight
) {
  const scale = Math.min(
    targetWidth / sourceWidth,
    targetHeight / sourceHeight
  );

  return {
    width: sourceWidth * scale,
    height: sourceHeight * scale,
    scale
  };
}

For cover:

function coverSize(
  sourceWidth,
  sourceHeight,
  targetWidth,
  targetHeight
) {
  const scale = Math.max(
    targetWidth / sourceWidth,
    targetHeight / sourceHeight
  );

  return {
    width: sourceWidth * scale,
    height: sourceHeight * scale,
    scale
  };
}

And stretch:

function stretchSize(
  targetWidth,
  targetHeight
) {
  return {
    width: targetWidth,
    height: targetHeight
  };
}

Calculating the centered crop for cover

If you use cover, you need to decide which part of the oversized result remains visible.

For centered placement:

function getCoverPlacement(
  sourceWidth,
  sourceHeight,
  targetWidth,
  targetHeight
) {
  const scale = Math.max(
    targetWidth / sourceWidth,
    targetHeight / sourceHeight
  );

  const renderedWidth =
    sourceWidth * scale;

  const renderedHeight =
    sourceHeight * scale;

  return {
    x:
      (targetWidth - renderedWidth)
      / 2,

    y:
      (targetHeight - renderedHeight)
      / 2,

    width: renderedWidth,
    height: renderedHeight
  };
}

Notice that x or y may be negative.

That is not a bug.

It means the oversized image extends outside the target canvas.

Draw the cover result to Canvas

function drawCover(
  ctx,
  image,
  targetWidth,
  targetHeight
) {
  const scale = Math.max(
    targetWidth / image.width,
    targetHeight / image.height
  );

  const width =
    image.width * scale;

  const height =
    image.height * scale;

  const x =
    (targetWidth - width) / 2;

  const y =
    (targetHeight - height) / 2;

  ctx.drawImage(
    image,
    x,
    y,
    width,
    height
  );
}

This gives you behavior similar to:

object-fit: cover;
object-position: center;

Draw the contain result

function drawContain(
  ctx,
  image,
  targetWidth,
  targetHeight
) {
  const scale = Math.min(
    targetWidth / image.width,
    targetHeight / image.height
  );

  const width =
    image.width * scale;

  const height =
    image.height * scale;

  const x =
    (targetWidth - width) / 2;

  const y =
    (targetHeight - height) / 2;

  ctx.drawImage(
    image,
    x,
    y,
    width,
    height
  );
}

If you want a padded background:

ctx.fillStyle = "#ffffff";

ctx.fillRect(
  0,
  0,
  targetWidth,
  targetHeight
);

drawContain(
  ctx,
  image,
  targetWidth,
  targetHeight
);

Crop and cover are related, but not identical UX concepts

From the user's perspective, "cover" often means automatic cropping.

But a good product may allow the user to control the crop anchor.

For example:

center
top
bottom
left
right
face position
manual focal point

If the subject is on the left side of a photo, centered cropping can cut it out.

So production resizing tools often need a focal point:

const focalPoint = {
  x: 0.25,
  y: 0.5
};

where:

0 = left/top
1 = right/bottom

Then the crop can be biased toward the important subject.

Why social-media resizing is mostly an aspect-ratio problem

Different platforms request different output canvases.

Examples include:

1:1
4:5
9:16
16:9

The annoying part is not just typing a new width and height.

It is deciding:

What should happen to the original composition when its aspect ratio does not match the destination?

That is why a useful social image workflow needs more than a width/height input.

It needs fit behavior.

On BatchSet's Social Media Resizer I expose this directly as modes such as:

Crop
Pad
Stretch

with predefined platform sizes.

The tool currently includes 28 presets across eight platforms, so the workflow becomes:

upload once
→ choose destinations
→ choose fit behavior
→ export

instead of manually creating each canvas.

If you already understand the geometry and just want the outputs:

Try BatchSet's Social Media Image Resizer

What about CSS?

For display-only UI, CSS already solves this elegantly.

.image {
  width: 1080px;
  height: 1350px;
  object-fit: cover;
}

MDN's object-fit documentation explains these behaviors.

But CSS only changes how the image is displayed.

It does not necessarily create a new exported file at that target size.

When users need an actual:

1080 × 1350 PNG

or:

1080 × 1920 JPG

you need rendering and export logic.

Don't resize by changing only one dimension blindly

A common implementation mistake:

canvas.width = 1080;
canvas.height = 1350;

ctx.drawImage(
  image,
  0,
  0,
  1080,
  1350
);

This is stretch.

If that is not intentional, the output will be distorted.

Always define the desired behavior explicitly.

A reusable fitting function

You can unify the modes:

function fitImage({
  sourceWidth,
  sourceHeight,
  targetWidth,
  targetHeight,
  mode
}) {
  if (mode === "stretch") {
    return {
      x: 0,
      y: 0,
      width: targetWidth,
      height: targetHeight
    };
  }

  const ratioX =
    targetWidth / sourceWidth;

  const ratioY =
    targetHeight / sourceHeight;

  const scale =
    mode === "cover"
      ? Math.max(ratioX, ratioY)
      : Math.min(ratioX, ratioY);

  const width =
    sourceWidth * scale;

  const height =
    sourceHeight * scale;

  return {
    x: (targetWidth - width) / 2,
    y: (targetHeight - height) / 2,
    width,
    height
  };
}

Now your renderer can work with a single object.

Final takeaway

Image resizing is not just "change width and height."

It is a trade-off between three goals:

preserve aspect ratio
show all source content
fill the entire target

You can reliably achieve two of the three.

That gives you:

contain
cover
stretch

Once you know the formulas, image-resizing behavior stops feeling arbitrary.

And more importantly, you can choose the right mode intentionally instead of discovering it after your user's face gets cropped out of the final export.

Your JPEG May Contain GPS Data: How EXIF Metadata Works and How to Strip It Before Sharing

Muhaymin Bin Mehmood — Fri, 28 Aug 2026 14:00:00 +0000

A photo can reveal more than what is visible in the pixels.

Depending on how it was created and processed, an image file may contain metadata describing things such as:

camera model
capture time
orientation
lens information
exposure settings
software used to edit the file
GPS coordinates

That means a photo of your desk could potentially reveal where the photo was taken even if the location is nowhere in the visible image.

This is not a reason to panic about every JPEG on the internet.

It is a reason to understand what you are actually sharing when you share an image file.

Pixels and metadata are different things

When developers think about images, we often think about the visible raster:

width × height × pixels

But formats such as JPEG can also contain additional structured information.

Conceptually:

JPEG
├── compressed pixel data
├── EXIF metadata
├── color information
├── thumbnails
└── other application-specific segments

The visible photo is only one part of the file.

This distinction becomes important when a product supports:

image uploads
public profile photos
marketplace listings
customer-submitted photos
journalism
moderation systems
document uploads
location-sensitive content

What is EXIF?

EXIF stands for Exchangeable Image File Format.

It is commonly associated with camera-generated metadata.

A simplified representation might look like:

{
  "Make": "Example Camera",
  "Model": "Example Model",
  "DateTimeOriginal": "2026:08:28 14:32:12",
  "Orientation": 1,
  "GPSLatitude": 31.5204,
  "GPSLongitude": 74.3587
}

Not every image contains every field.

Some applications also rewrite or remove metadata automatically.

The important point is that metadata can exist inside the file, separate from the visible image.

Why developers should care about GPS metadata

Imagine a platform where users upload photos of:

their home setup
a product they want to sell
a child
a damaged vehicle
a confidential work environment

If the original photo contains location metadata and the platform republishes the file without a metadata policy, that information may travel with it.

A more privacy-conscious pipeline might be:

User uploads image
        ↓
Decode / inspect metadata
        ↓
Apply metadata policy
        ↓
Generate public derivative
        ↓
Publish derivative

The phrase metadata policy matters.

Not every application should blindly strip everything.

When metadata should be preserved

Metadata can be useful.

Examples:

Photography workflows

A photographer may need:

aperture
shutter speed
focal length
ISO
capture date

Scientific or field data

Location and capture time may be part of the actual dataset.

Asset-management systems

Metadata can help organize a large library.

Forensic workflows

Original file information may be important evidence.

In these cases, stripping metadata indiscriminately could destroy useful information.

When metadata should probably be removed

For a public derivative, you may want a stricter policy.

Examples:

Public social/profile uploads

Camera details and GPS rarely add value.

Marketplace product images

The customer needs to see the product, not where the seller photographed it.

Public support screenshots

Extra file metadata is usually irrelevant.

Marketing assets

The final public image generally does not need private capture information.

A common strategy is:

Original asset:
preserve

Public derivative:
strip unnecessary metadata

That gives you both archival integrity and safer public distribution.

Inspecting EXIF in JavaScript

The browser does not provide a single built-in API that turns arbitrary EXIF into a friendly JavaScript object.

In practice, applications often use a parsing library.

A conceptual example:

async function inspectImage(file) {
  const metadata =
    await exifLibrary.parse(file);

  return {
    camera: metadata.Model,
    takenAt:
      metadata.DateTimeOriginal,
    latitude:
      metadata.latitude,
    longitude:
      metadata.longitude
  };
}

The exact API depends on the library you choose.

The important architectural separation is:

File bytes
   ↓
Metadata parser
   ↓
Application policy
   ↓
Keep / remove / selectively retain

Re-encoding can remove metadata — but be careful

A common browser strategy is:

decode the image into pixels
draw the pixels to Canvas
re-encode the Canvas as a new image

For example:

async function reencodeImage(file) {
  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);

  return await new Promise(
    (resolve, reject) => {
      canvas.toBlob(
        (blob) => {
          if (blob) {
            resolve(blob);
          } else {
            reject(
              new Error(
                "Encoding failed"
              )
            );
          }
        },
        "image/jpeg",
        0.9
      );
    }
  );
}

This creates a new encoded file from rendered pixels.

But there are trade-offs.

Re-encoding is not the same as lossless metadata editing

If the input is JPEG and you decode/re-encode it as JPEG, you are creating a new compressed representation.

That can affect:

file size
quality
color behavior
orientation behavior

If your only goal is metadata editing, a specialized metadata-aware approach may be more appropriate.

So think about the job in two categories:

Pixel transformation

decode → transform → encode

Metadata transformation

parse file structure
→ modify metadata segments
→ preserve intended image data

They are related, but not identical.

Orientation is a classic metadata trap

Historically, some photos stored camera orientation in EXIF rather than physically rotating the pixel matrix.

That meant an image could have:

pixel data: landscape
EXIF orientation: rotate 90°

Applications that ignored the orientation tag could display the image sideways.

Modern browser behavior has improved, but orientation remains a good example of why metadata is not always "junk."

If you remove metadata as part of a processing pipeline, verify that your final pixels are already rendered in the intended orientation.

A safer application policy

A useful policy can be written explicitly.

const metadataPolicy = {
  publicUpload: {
    gps: "remove",
    device: "remove",
    captureTime: "remove",
    orientation: "normalize"
  },

  originalArchive: {
    gps: "preserve",
    device: "preserve",
    captureTime: "preserve",
    orientation: "preserve"
  }
};

The exact rules will depend on your product.

The important part is that the decision is intentional.

Client-side processing has a privacy advantage

There is another layer to the discussion.

Suppose the user's goal is simply:

Remove metadata from this photo before I share it.

If the image can be processed locally in the browser, the user does not necessarily need to upload the original file to a server just to get a cleaned copy.

A local workflow looks like:

Original image
     ↓
Browser
     ↓
Metadata processing / re-encode
     ↓
Cleaned output
     ↓
Download

That architecture reduces the number of systems that ever receive the original asset.

It does not automatically make every implementation secure, but it is a useful privacy property.

What I would log — and what I would not

If you build an image-processing product, analytics can accidentally undermine your privacy design.

Good analytics:

{
  "tool": "metadata-processing",
  "inputType": "image/jpeg",
  "success": true,
  "fileCountBucket": "1"
}

Bad analytics:

{
  "filename": "home-address-photo.jpg",
  "gps": "31.5204,74.3587",
  "cameraSerial": "..."
}

You usually do not need private metadata to understand whether your product works.

Measure the operation, not the user's content.

How I think about EXIF in BatchSet

While working on BatchSet's image-processing pipeline, I found that metadata controls are easy to present as a tiny checkbox but deserve much more deliberate product thinking.

A useful UI may say:

Keep metadata
Strip metadata

But behind those two options are several questions:

Which metadata?
Which formats?
Is orientation normalized?
Is the image re-encoded?
Is the operation local or server-side?
Does the user need the original metadata later?

That is why I prefer treating metadata as a separate processing decision rather than a side effect of conversion.

BatchSet currently exposes EXIF/metadata controls within its image conversion workflow, with advanced metadata capabilities tied to the product's current feature/pricing rules.

If you want to review the image-processing options directly:

Open BatchSet's image converter

A simple pre-publish checklist

Before publicly sharing a sensitive photo, ask:

Do I need the original file publicly?
Do I need the original metadata publicly?
Could the metadata expose location?
Could it expose a capture time I do not want public?
Could removing it break orientation?
Can I publish a cleaned derivative instead?

That final question is often the most useful.

You can preserve your original privately while publishing a processed copy.

Final takeaway

An image is not always just pixels.

When you accept, process, or publish user-generated images, treat metadata as part of your data model.

The safest default is not necessarily "strip everything."

The safer engineering approach is:

know what is inside the file, decide what your product needs, and intentionally control what leaves the system.

SVG to PNG in the Browser: Rasterization, Transparency, Fonts, and a Production-Safe JavaScript Pipeline

Muhaymin Bin Mehmood — Thu, 27 Aug 2026 14:00:00 +0000

An SVG can look perfect in a browser and still fail the moment you need to upload it somewhere that only accepts PNG.

That sounds like a simple format conversion problem.

It isn't.

When you convert JPEG to WebP, you are mostly changing how a raster image is encoded. When you convert SVG to PNG, the browser has to do something more fundamental:

turn vector instructions into pixels.

That means deciding how large the pixel grid should be, resolving SVG dimensions, loading fonts, rendering shapes, preserving transparency, and only then encoding the final result as PNG.

In this article, I'll build that pipeline in JavaScript and focus on the parts that usually break in real applications.

SVG and PNG represent images differently

An SVG is not a grid of pixels.

It can describe:

paths
lines
text
gradients
masks
filters
transforms
embedded assets

A PNG, on the other hand, stores a fixed raster.

So before converting an SVG, you have to answer an important question:

At what resolution should this vector be rendered?

For example, this SVG:

<svg viewBox="0 0 512 512">
  ...
</svg>

does not necessarily mean the output PNG must be exactly 512 × 512.

You could render it as:

512 × 512
1024 × 1024
2048 × 2048

and the vector geometry would still be sharp before rasterization.

Once you create the PNG, however, the result is locked to the chosen pixel dimensions.

The browser pipeline

A simple client-side SVG → PNG pipeline looks like this:

SVG file
   ↓
Read SVG
   ↓
Resolve width / height / viewBox
   ↓
Decode SVG as an image
   ↓
Draw it onto Canvas
   ↓
Encode Canvas as PNG
   ↓
Create Blob URL
   ↓
Download

The two browser APIs doing most of the work are:

CanvasRenderingContext2D.drawImage()
HTMLCanvasElement.toBlob()

MDN documents both APIs in detail:

Let's build it.

Step 1: Read and validate the SVG

We'll start with a File.

async function svgToPng(file, scale = 2) {
  if (!(file instanceof File)) {
    throw new TypeError("Expected a File");
  }

  if (file.type !== "image/svg+xml") {
    throw new TypeError("Expected an SVG file");
  }

  const svgText = await file.text();

  // More work coming...
}

The MIME-type check is useful, but do not treat it as a security boundary by itself.

If your application accepts untrusted files, validate input more carefully.

Step 2: Resolve the SVG dimensions

SVGs can define their size in several ways.

You may see:

<svg width="800" height="600">

or:

<svg viewBox="0 0 800 600">

or both.

A robust converter should not assume width and height always exist.

const doc = new DOMParser().parseFromString(
  svgText,
  "image/svg+xml"
);

const svg = doc.documentElement;

const widthAttr = Number.parseFloat(
  svg.getAttribute("width") ?? ""
);

const heightAttr = Number.parseFloat(
  svg.getAttribute("height") ?? ""
);

const viewBox = (svg.getAttribute("viewBox") ?? "")
  .trim()
  .split(/\s+/)
  .map(Number);

const hasValidViewBox =
  viewBox.length === 4 &&
  viewBox.every(Number.isFinite);

const viewBoxWidth = hasValidViewBox
  ? viewBox[2]
  : NaN;

const viewBoxHeight = hasValidViewBox
  ? viewBox[3]
  : NaN;

const width = Number.isFinite(widthAttr)
  ? widthAttr
  : viewBoxWidth;

const height = Number.isFinite(heightAttr)
  ? heightAttr
  : viewBoxHeight;

if (!Number.isFinite(width) || !Number.isFinite(height)) {
  throw new Error(
    "SVG needs usable width/height or a viewBox"
  );
}

This is already better than the classic:

canvas.width = img.width;
canvas.height = img.height;

because many real SVG assets depend on viewBox.

Step 3: Create a Blob URL

We can turn the SVG text into a temporary browser URL.

const objectUrl = URL.createObjectURL(
  new Blob([svgText], {
    type: "image/svg+xml"
  })
);

Then load it into an Image.

const image = await new Promise(
  (resolve, reject) => {
    const img = new Image();

    img.onload = () => resolve(img);

    img.onerror = () => {
      reject(
        new Error("Could not decode the SVG")
      );
    };

    img.src = objectUrl;
  }
);

Do not draw before the image has loaded.

That sounds obvious, but race conditions here are one of the easiest ways to get blank PNGs.

Step 4: Wait for fonts

Text inside an SVG can depend on fonts that are not ready yet.

If the SVG relies on a custom font and you rasterize too early, the browser can render a fallback font instead.

For document-level fonts, you can wait for:

await document.fonts?.ready;

The browser's CSS Font Loading API gives you more control when font timing matters.

This becomes especially important for:

logos with text
certificates
social graphics
branded SVG exports
dynamically generated charts

Step 5: Create the raster canvas

Now we choose the actual PNG resolution.

const canvas = document.createElement(
  "canvas"
);

canvas.width = Math.round(width * scale);
canvas.height = Math.round(height * scale);

const ctx = canvas.getContext("2d");

if (!ctx) {
  throw new Error(
    "2D canvas is unavailable"
  );
}

If scale = 2, a 512 × 512 SVG becomes a 1024 × 1024 PNG.

Important distinction:

we are not upscaling an existing bitmap.

We are rasterizing vector geometry directly onto a larger pixel grid.

That is why a larger render can still look sharp.

Step 6: Preserve transparency

A new canvas is transparent by default.

So if your SVG has transparent regions and you want them preserved in the PNG, simply do not paint a background first.

ctx.drawImage(
  image,
  0,
  0,
  canvas.width,
  canvas.height
);

If you need a white background instead:

ctx.fillStyle = "#ffffff";

ctx.fillRect(
  0,
  0,
  canvas.width,
  canvas.height
);

ctx.drawImage(
  image,
  0,
  0,
  canvas.width,
  canvas.height
);

The difference matters for:

logos
icons
UI assets
product overlays
stickers
presentation graphics

Step 7: Encode Canvas as PNG

Use toBlob() rather than building a huge base64 data URL.

const pngBlob = await new Promise(
  (resolve, reject) => {
    canvas.toBlob(
      (blob) => {
        if (!blob) {
          reject(
            new Error("PNG encoding failed")
          );

          return;
        }

        resolve(blob);
      },
      "image/png"
    );
  }
);

Then return it:

return pngBlob;

Complete converter

Here's the full version:

async function svgToPng(
  file,
  scale = 2
) {
  if (
    !(file instanceof File) ||
    file.type !== "image/svg+xml"
  ) {
    throw new TypeError(
      "Expected an SVG file"
    );
  }

  const svgText = await file.text();

  const doc = new DOMParser()
    .parseFromString(
      svgText,
      "image/svg+xml"
    );

  const svg = doc.documentElement;

  const widthAttr =
    Number.parseFloat(
      svg.getAttribute("width") ?? ""
    );

  const heightAttr =
    Number.parseFloat(
      svg.getAttribute("height") ?? ""
    );

  const viewBox =
    (svg.getAttribute("viewBox") ?? "")
      .trim()
      .split(/\s+/)
      .map(Number);

  const validViewBox =
    viewBox.length === 4 &&
    viewBox.every(Number.isFinite);

  const width =
    Number.isFinite(widthAttr)
      ? widthAttr
      : validViewBox
        ? viewBox[2]
        : NaN;

  const height =
    Number.isFinite(heightAttr)
      ? heightAttr
      : validViewBox
        ? viewBox[3]
        : NaN;

  if (
    !Number.isFinite(width) ||
    !Number.isFinite(height)
  ) {
    throw new Error(
      "SVG needs usable dimensions"
    );
  }

  const objectUrl =
    URL.createObjectURL(
      new Blob(
        [svgText],
        { type: "image/svg+xml" }
      )
    );

  try {
    const image =
      await new Promise(
        (resolve, reject) => {
          const img = new Image();

          img.onload = () =>
            resolve(img);

          img.onerror = () =>
            reject(
              new Error(
                "Could not decode SVG"
              )
            );

          img.src = objectUrl;
        }
      );

    await document.fonts?.ready;

    const canvas =
      document.createElement(
        "canvas"
      );

    canvas.width =
      Math.round(width * scale);

    canvas.height =
      Math.round(height * scale);

    const ctx =
      canvas.getContext("2d");

    if (!ctx) {
      throw new Error(
        "2D canvas unavailable"
      );
    }

    ctx.drawImage(
      image,
      0,
      0,
      canvas.width,
      canvas.height
    );

    return await new Promise(
      (resolve, reject) => {
        canvas.toBlob(
          (blob) => {
            blob
              ? resolve(blob)
              : reject(
                  new Error(
                    "PNG encoding failed"
                  )
                );
          },
          "image/png"
        );
      }
    );
  } finally {
    URL.revokeObjectURL(
      objectUrl
    );
  }
}

Downloading the result

const pngBlob =
  await svgToPng(
    fileInput.files[0],
    2
  );

const downloadUrl =
  URL.createObjectURL(pngBlob);

const link =
  document.createElement("a");

link.href = downloadUrl;
link.download = "converted.png";
link.click();

URL.revokeObjectURL(
  downloadUrl
);

Production problem #1: remote assets and CORS

A self-contained local SVG is the easiest case.

The situation becomes more complicated if the SVG references resources hosted on another origin.

For example:

<image
  href="https://example.com/photo.jpg"
/>

The browser may allow the asset to render visually but prevent you from exporting the resulting canvas.

That is the infamous tainted canvas problem.

Once unauthorized cross-origin content reaches a Canvas, APIs such as toBlob() and toDataURL() can fail for security reasons.

MDN covers this under cross-origin images and Canvas.

Production problem #2: huge output dimensions

Suppose the input SVG describes:

4000 × 4000

and the user asks for 4×.

That would create:

16000 × 16000

which is:

256,000,000 pixels

Before encoding, Canvas may require a large amount of memory for that surface.

So production tools should enforce sensible limits.

A simple check:

const outputWidth = width * scale;
const outputHeight = height * scale;

const pixelCount =
  outputWidth * outputHeight;

const MAX_PIXELS = 80_000_000;

if (pixelCount > MAX_PIXELS) {
  throw new Error(
    "Requested output is too large"
  );
}

The exact limit should depend on your application and target browsers.

Production problem #3: dimensions are product decisions

A converter needs more than technically correct rendering.

It also needs a policy.

For example:

preserve original dimensions
use viewBox dimensions
render at 1× / 2× / 4×
let the user define width
maintain aspect ratio automatically
reject absurdly large targets

These choices determine whether the result is useful.

The conversion code is often the easy part.

The product behavior around it is the difficult part.

Why I prefer browser-side conversion for local SVGs

For a self-contained SVG, there is often no reason to upload the file to a server just to rasterize it.

A browser already has:

an SVG renderer
Canvas
Blob APIs
file access
download APIs

Keeping the operation local gives you an attractive architecture:

User file
   ↓
Browser memory
   ↓
Canvas
   ↓
PNG Blob
   ↓
User download

No temporary server upload is required.

That is particularly useful for:

internal company graphics
unpublished logos
client assets
product mockups
design-system icons

Build it or use a tool?

If SVG rasterization is part of your product, owning this pipeline makes sense.

You may need:

custom sizing
worker-based rendering
queue management
asset validation
custom fonts
telemetry
batch handling

But if you simply need to convert an SVG into PNG, maintaining a conversion pipeline is unnecessary work.

I added a dedicated browser-side SVG → PNG workflow to BatchSet for exactly that kind of task.

Need the PNG without maintaining rasterization code?

Try BatchSet's SVG → PNG converter

It is designed for the direct job: drop in an SVG, rasterize it to PNG in the browser, preserve transparency, and download the result without creating an account.

Final takeaway

SVG → PNG is not just "change the extension."

The browser has to:

understand the SVG
resolve dimensions
load dependencies
choose a pixel grid
rasterize the vector
encode the result

Once you understand that pipeline, bugs involving blurry output, missing fonts, blank canvases, lost transparency, and CORS become much easier to reason about.

And if you only need the finished PNG, the best code may be the code you do not have to maintain.

How I Built a Bulk Image Converter That Runs Entirely in Your Browser

Muhaymin Bin Mehmood — Tue, 25 Aug 2026 17:20:14 +0000

A few months ago, I needed to convert 400 product images from JPG to WebP for a Shopify store.

I tried the usual online converters. Every single one of them made me upload my files to a server, wait in a queue, and then download a ZIP. Some put watermarks on the free tier. Others capped me at 10 images unless I paid.

For 400 images, that workflow was painful. But the part that really bothered me was the upload. These were product photos. I did not want them sitting on someone else's server, even temporarily.

So I built BatchSet, a bulk image converter that runs entirely in your browser. No upload. No signup. No watermark. You drop your images, they convert locally, and you download the ZIP.

This post is about how the browser-side pipeline works, where it breaks down, and why "client-side only" is both more powerful and more limited than you might think.

The Core Pipeline

The browser can do a surprising amount of image processing today. The core loop in BatchSet looks like this:

User drops files
    |
FileReader reads as ArrayBuffer
    |
createImageBitmap decodes in a Web Worker
    |
OffscreenCanvas draws + encodes to target format
    |
JSZip packages everything
    |
Auto-download ZIP

Let me break down the key parts.

1. createImageBitmap: the decoder

Most people still use new Image() or canvas.drawImage() with a source image. That works, but it runs on the main thread and blocks the UI.

createImageBitmap is different. It decodes the image off the main thread and returns an ImageBitmap you can draw to any canvas without re-decoding.

// Inside a Web Worker
const bitmap = await createImageBitmap(file);

This is fast. For a typical 2MB product photo, decoding takes 20-40ms. The real win is that it does not block the UI thread, so the progress bar stays smooth even when processing hundreds of images.

2. OffscreenCanvas: the encoder

Once you have the decoded bitmap, you need to encode it to the target format. For WebP, JPG, or PNG output, you draw the bitmap to an OffscreenCanvas and call convertToBlob.

const canvas = new OffscreenCanvas(width, height);
const ctx = canvas.getContext('2d');
ctx.drawImage(bitmap, 0, 0, width, height);

const blob = await canvas.convertToBlob({
  type: 'image/webp',
  quality: 0.80
});

OffscreenCanvas works inside a Web Worker, so the heavy encoding work (especially for large images or high quality) does not freeze the tab.

3. Web Workers: parallel processing

The real gain comes from running multiple workers in parallel. BatchSet spawns one worker per logical CPU core using navigator.hardwareConcurrency.

const workers = [];
const cores = navigator.hardwareConcurrency || 4;

for (let i = 0; i < cores; i++) {
  workers.push(new Worker('/worker.js'));
}

Images are distributed round-robin across workers. On a modern laptop with 8 cores, 8 images are being decoded and encoded simultaneously. A batch of 200 images that takes about 60 seconds sequentially finishes in under 10 on my machine.

4. JSZip: packaging without memory explosions

The tricky part with bulk conversion is not the processing. It is the memory.

If you hold every converted image in memory before creating the ZIP, a 500-image batch will crash the tab. Browsers cap how much memory a single tab can use, usually somewhere in the 2-4GB range depending on the device.

BatchSet streams images into JSZip incrementally using Blobs rather than base64 strings. Base64 inflates size by roughly 33%. Blobs do not.

Even then, for very large batches (500+ high-res images), the browser will eventually hit the wall. The honest fix is to split into smaller batches, or tell the user their device is the bottleneck.

What the Browser Cannot Do (Yet)

The client-side pipeline handles JPG, PNG, WebP, GIF, BMP, and SVG well. Some formats it simply cannot:

HEIC — iPhone photos. No native browser encoder. We use Sharp on the server for these.
TIFF — no browser support at all. Server-side only.
Exact target file size — browser encoding APIs do not let you say "make this exactly 150KB." That needs iterative re-encoding, which is cheaper to do server-side with Sharp.
Watermarking with complex fonts and layouts — possible in canvas, but messy. Server-side is more reliable.

So the architecture is not "browser only." It is "browser by default, server for the exceptions."

The Privacy Angle

This is the part that surprised me most. When I posted about BatchSet on LinkedIn, the response was not "this is fast." It was "this is private."

A lot of people process client work, product photos, or internal documents they do not want on a cloud server. "We delete after an hour" is not enough for them. "Never uploaded" is.

The browser-side approach means:

Your images never touch a server
There is no network upload time
There is no queue
There is no "trust us" privacy policy

The trade-off is that your device does the work. On an old laptop with 4GB RAM, a 200-image batch will struggle. On a modern machine, it flies.

Performance: Browser vs Server

I ran a rough benchmark converting 100 product images (average 2.4MB JPG) to WebP at 80% quality, on my own connection and machine. Your numbers will differ, especially on upload-heavy paths:

Approach	Time	Upload?	Where it runs
Browser, 8 cores	48s	No	Local
Browser, 4 cores	1m 35s	No	Local
Typical server-based converter (free tier)	4-7m	Yes	Server

The browser wins on wall-clock time mostly because there is no upload/download round-trip. The actual encoding is roughly comparable; skipping the network is what saves minutes.

The Code

Here is a minimal version of the core worker that handles conversion:

// image-worker.js
self.onmessage = async (e) => {
  const { file, format, quality, maxWidth } = e.data;

  try {
    // Decode
    const bitmap = await createImageBitmap(file);

    // Calculate new dimensions
    let { width, height } = bitmap;
    if (maxWidth && width > maxWidth) {
      height = Math.round(height * (maxWidth / width));
      width = maxWidth;
    }

    // Draw and encode
    const canvas = new OffscreenCanvas(width, height);
    const ctx = canvas.getContext('2d');
    ctx.drawImage(bitmap, 0, 0, width, height);

    const mime = format === 'webp' ? 'image/webp' : 'image/jpeg';
    const blob = await canvas.convertToBlob({ type: mime, quality });

    // Send back
    self.postMessage({ blob, name: file.name });
  } catch (err) {
    self.postMessage({ error: err.message });
  }
};

The main thread just coordinates: it distributes files to workers, collects results, and streams them into JSZip.

What I Learned

1. RAM is the real bottleneck. CPU is rarely the issue. Memory management and incremental ZIP writing matter more than parallelization.

2. Progress bars are non-negotiable. When processing 200 images, users need to see movement. A frozen UI feels broken even when the worker is busy.

3. Fallbacks matter. Safari handles OffscreenCanvas differently from Chrome. Firefox has different memory limits. Test on all three.

4. Honest limitations build trust. I originally hid the fact that large batches could crash the tab. Now the UI warns you: "Very large batches are limited by your device's RAM." Users appreciate that more than a silent crash.

Try It

The core image converter is free and requires no account:

batchset.com/tools/bulk-image-converter

Drop a folder of images, pick WebP or JPG, set your quality, and download the ZIP. Everything happens in your browser.

The other tools (barcodes, QR codes, URL shortening, social resizing, AI background removal) are built around the same principle: do as much as possible locally, and only hit the server when the browser genuinely cannot.

Questions?

Happy to answer anything about the browser-side pipeline, memory management with large batches, or where this approach falls apart. Drop a comment below.

Built with Next.js 14, Web Workers, and too much coffee.

Why Large Product Images Are Killing Your Store's Core Web Vitals (And How to Automate the Fix)

Muhaymin Bin Mehmood — Mon, 13 Jul 2026 19:30:00 +0000

Let’s face a hard truth: If your e-commerce store takes more than 3 seconds to load, you are actively giving away money to your competitors.

In modern web development, performance isn't just a vanity metric—it’s directly tied to your bottom line. Google explicitly uses Core Web Vitals as a ranking factor, and among them, Largest Contentful Paint (LCP) is often the hardest one for online stores to ace.

The number one culprit? Heavy, unoptimized product images.

In this guide, we’ll dive into why massive product photography destroys your store's performance metrics and how you can use smart automation to optimize your entire visual asset pipeline without spending hours inside editing software.

The Core Web Vitals Problem: Meet LCP

Largest Contentful Paint (LCP) measures how long it takes for the largest visual element on the screen—usually a hero banner or a primary product image—to become fully rendered.

When a user lands on a product page, their browser has to fetch the HTML, parse the CSS, and pull down the product imagery. If your catalog consists of raw, uncompressed 3MB JPGs straight out of a DSLR camera:

The browser gets bottlenecked trying to download massive payloads.
Your LCP score plummets into the "Poor" red zone.
High latency triggers a higher bounce rate, causing shoppers to leave before they even see what you are selling.

The Next-Gen Format Solution: WebP and Beyond

To optimize your storefront, legacy formats like standard JPG and PNG won't cut it anymore. Moving your catalog to modern image formats like WebP or AVIF provides superior compression features:

Format	Average Size Reduction	Transparency Support	Best Use Case
PNG	0% (Baseline)	Yes	High-quality source images
WebP	25% - 35% smaller than JPEG	Yes	Standard web & product catalogs
AVIF	50% smaller than JPEG	Yes	Next-gen performance matching

By switching to compressed, transparent web formats, you can drop your image payload sizes significantly without losing visible picture quality.

The Developer's Nightmare: Manual Bulk Editing

While switching formats sounds simple, executing it across an active store with hundreds or thousands of SKUs is an absolute nightmare.

Manually opening Photoshop, stripping backgrounds, resizing dimensions, and exporting files one by one eats up hours of developer or marketing team time. Writing custom localized CLI scripts using tools like Sharp or ImageMagick works, but setting up a reliable pipeline that your non-technical team members can easily use is a distraction from building core storefront features.

Streamlining the Workflow with Automation

This is exactly why automated workflow tools are crucial. Instead of fighting with complex processing scripts or tedious manual software, you can offload the entire process to cloud-based batch tools.

With platform pipelines like BatchSet, you can drop an entire folder of product photos into a unified workspace. The platform handles the heavy lifting in parallel:

Automatic Background Removal: Strips away cluttered rooms, backdrops, or shadows instantly.
Standardized Formatting: Normalizes canvas borders and auto-centers the items across the entire collection.
Web Optimization: Converts assets instantly into highly-compressed, crisp transparent formats ready for rapid production deployment.


css
/* Pro Tip: Lazy-load your optimized images to keep initial LCP low */
.product-hero-image {
  content-visibility: auto;
  loading: lazy;
  object-fit: contain;
}

AI Background Removal for Product Photos: The Ultimate Guide 🚀

Muhaymin Bin Mehmood — Mon, 13 Jul 2026 16:11:00 +0000

Ever wondered why some e-commerce stores look like a high-end luxury brand while others look like a sketchy garage sale?

Spoiler alert: It’s usually the backgrounds. A product shot sitting on a cluttered office desk or a wrinkled bedsheet doesn’t just look unpolished—it actively kills conversions. Buyers associate a clean, isolated product shot with a legitimate, professional brand. A messy background screams amateur.

In this guide, we’ll look at why background removal is actually a sales problem, how the tech works under the hood, and how to strip backgrounds from your entire catalog in one click using tools like BatchSet—completely free.

Why Background Removal is a Sales Problem (Not Just a Design One)

Every major marketplace and ad platform rewards clean, distraction-free imagery.

Amazon & Daraz: Mandate pure white backgrounds for primary product images.
Shopify: Themes look significantly more premium with cut-out product shots layered over consistent brand colors.
Instagram & Facebook Ads: Clean, isolated products perform better because they can be easily dropped onto any engaging ad backdrop.

How AI Background Removal Actually Works 🧠

Historically, removing a background meant sitting in Photoshop for 15 minutes per image, tediously clicking with the Pen Tool or dealing with messy Magic Wand edges.

Modern AI background removers use deep learning neural networks (specifically Computer Vision models) trained on millions of product images. The AI does two things simultaneously:

Object Detection: It identifies what the actual product is (the foreground).
Semantic Segmentation: It maps out the exact boundaries of the object, right down to complex details like fabric fringes, translucent bottles, or fine textures.

The result? You get a studio-quality transparent PNG file in less than 3 seconds without lifting a finger.

How to Remove a Background in 3 Simple Steps

You don’t need Photoshop or expensive design software. Here is how you can do it right in your browser with the BatchSet Background Remover:

Step 1: Upload Your Images

Drag and drop your raw product photos (JPG, PNG, or WebP) straight into the web interface.

Step 2: Let the AI Process

The AI automatically detects your product boundaries and instantly strips away the backdrop.

Step 3: Choose Your Export Format

Download your image as a transparent PNG, or select a solid color preset (like crisp white #FFFFFF) to meet marketplace guidelines instantly.

Scaling Up: Bulk Background Removal for Full Catalogs 📦

If you have 50, 100, or thousands of SKUs, doing them one by one is still a headache. That’s where Batch Processing comes in.

Instead of repeating the process, you can upload your entire product line in batches. The AI applies the exact same cutout rules, centering alignment, and background colors across every single file, giving you a perfectly uniform catalog in a fraction of the time.

💡 Quick Tip for the Best AI Cutouts:
For flawless edges, try to shoot your original photos with good lighting and a decent amount of contrast between the product and the background. It gives the neural network the best data to work with!

Integrating Clean Cutouts into Your Frontend

If you are a developer building a custom Shopify storefront or e-commerce app, using transparent PNGs gives you massive CSS flexibility. For example, you can effortlessly change your site's aesthetic or card backgrounds without re-editing your images:


css
/* Easily swap product card themes when using transparent PNG assets */
.product-card {
  background-color: #f4f4f5; /* Light minimalist grey */
  border-radius: 8px;
  transition: background 0.3s ease;
}

.product-card:hover {
  background-color: #e4e4e7; /* Smooth hover state */
}

Did you guys tried yet!

Muhaymin Bin Mehmood — Wed, 08 Jul 2026 11:01:11 +0000

Muhaymin Bin Mehmood

Jun 8

BatchSet is Live on Product Hunt 🚀 — 30% Off for the DEV Community (Code: PRODUCTHUNT)

#showdev #webdev #ecommerce #productivity

2 min read

Why Your Images Are Killing Your Core Web Vitals (and How I Fixed It in One Afternoon)

Muhaymin Bin Mehmood — Wed, 08 Jul 2026 10:34:35 +0000

The problem nobody notices until it's a problem

Run PageSpeed Insights on almost any e-commerce store, blog, or portfolio site and you'll find the same culprit sitting at the top of the report: images. Not your JS bundle, not your fonts — images, usually accounting for 60–70% of total page weight.

It's an easy thing to ignore because it doesn't feel like a "real" performance problem. Nobody profiles a <img> tag the way they profile a slow API call. But Largest Contentful Paint (LCP) — one of Google's three Core Web Vitals — is, on most pages, literally an image. If that image is a 2–4MB JPEG straight off a phone camera, you've already lost the metric before a single line of your carefully optimized JS runs.

Why WebP (and not just "compress the JPEG")

The instinct is usually "run it through TinyPNG." That helps, but it's solving the wrong layer of the problem — you're still stuck with JPEG's compression algorithm, which is decades old at this point.

WebP, developed by Google, uses a more modern compression scheme and consistently produces 60–80% smaller files than JPEG at equivalent visual quality. Not "smaller with artifacts" — smaller at the same perceptual quality. It also supports alpha transparency (like PNG) and animation (like GIF), so in most cases it replaces all three formats outright.

Browser support is no longer a concern — WebP sits at 97%+ global browser support in 2026, including Safari since v14. If you're still shipping fallback JPEGs "just in case," you're probably not gaining much from it anymore.

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

If you want to squeeze out another 20–30%, AVIF (AV1-based) beats WebP on file size, at the cost of slower encoding and slightly less universal support. Good rule of thumb: WebP as your baseline, AVIF as the power-user upgrade if you have the batch-processing time to spare.

The actual annoying part: doing this at scale

Converting one image is a 10-second problem — drag a file into any online converter and you're done. Converting a catalog of 300 product images, each needing resize + format conversion + a consistent quality setting, is a completely different problem. Doing it by hand in Photoshop is an afternoon you don't get back. Writing a one-off script with sharp or imagemagick works, but it's yet another thing to maintain for what should be a five-minute task.

This is the exact gap I built BatchSet to close — a browser-based bulk image tool with two ingestion paths that matter for real workflows:

File upload batch — drop in hundreds of images, apply one shared setting (or per-file overrides), get a ZIP back
Spreadsheet/URL batch — paste a column of image URLs (e.g. exported straight from a Shopify or WooCommerce product catalog) and it fetches, converts, and zips every one — no manual download/re-upload loop

It also does AI background removal (segmentation-model cutouts to transparent PNG), which used to require actual Photoshop skill and now doesn't.

Input formats:  JPG, JPEG, PNG, WebP, GIF, BMP, TIFF, SVG
Output formats: JPG, PNG, WebP, GIF, BMP, TIFF, PDF

Basic conversion (WebP/JPG/PNG) is free and unlimited, no signup required — I wanted the "just let me convert one image real quick" use case to have zero friction, since that's most of what people actually need.

A quick before/after

Real numbers from converting a standard e-commerce product photo:

	Original JPEG	WebP (q80)	AVIF
2400×2400 product shot	1.8 MB	~210 KB	~150 KB
Reduction	—	-88%	-92%

Multiply that across a few hundred product images and you're talking about a genuinely different LCP score, not a rounding error.

Takeaway

If you haven't audited your image pipeline recently, it's probably the highest-ROI performance work available to you right now — more impactful than most JS micro-optimizations, and far less effort than most people assume once you're doing it in batches instead of one file at a time.

Curious what tools/approaches other people here are using for this — curious if anyone's gone all-in on AVIF yet or still holding at WebP for the encoding-speed tradeoff.

I built BatchSet as a free bulk image converter (WebP/AVIF/JPG/PNG + AI background removal + Excel/URL batch mode) — happy to answer questions on the compression side in the comments.

DEV Community: Muhaymin Bin Mehmood

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

Local files and remote URLs are different trust boundaries

What happens with fetch()

Why browsers enforce this

The Canvas version of the problem

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

Architecture 1: fully browser-side when sources support CORS

Architecture 2: server-side fetch layer

Server-side URL fetching creates SSRF risk

A safer remote-fetch checklist

Validate actual image content

Parse the spreadsheet in the browser first

Example CSV workflow

Queueing matters at 500 URLs

Failure reporting is part of the feature

Why the browser-only rule should not become ideology

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

Product insight: architecture can become a marketing advantage

Final takeaway

EAN-13 and UPC-A Check Digits Explained: Build a Barcode Validator in JavaScript

What a check digit does

EAN-13 structure

EAN-13 check digit algorithm

A clean JavaScript implementation

Generate a complete EAN-13 number

Validate an existing EAN-13

A more generic Mod-10 function

UPC-A example

Why modulo 10?

Check digits are validation, not uniqueness

Barcode data vs barcode image

Why this matters in e-commerce tooling

Batch generation adds product-level complexity

Useful test cases

Final takeaway

SVG PNG looks simple. It isn’t. Here’s what actually happens inside the browser. 👇

SVG to PNG in the Browser: Rasterization, Transparency, Fonts, and a Production-Safe JavaScript Pipeline

PDF to JPG/PNG in the Browser: Rendering Pages with PDF.js Without Uploading the Document

Mental model: render first, encode second

Load a PDF

Render one page

Why scale matters

Export as PNG

Export as JPEG

Download the page

Render a page range

Do not render 100 pages simultaneously

Sequential renderer

PDF → Image is not image extraction

Handling passwords and invalid PDFs

Progress matters

ZIP download is the natural multi-page output

Why local processing is useful for PDFs

Final takeaway

Cover vs Contain vs Stretch: The Image-Resizing Math Frontend Developers Should Understand

Start with aspect ratio

Contain

Cover

Stretch

The three modes in one table

JavaScript implementation

Calculating the centered crop for cover

Draw the cover result to Canvas

Draw the contain result

Crop and cover are related, but not identical UX concepts

Why social-media resizing is mostly an aspect-ratio problem

What about CSS?

Don't resize by changing only one dimension blindly

A reusable fitting function

Final takeaway

Your JPEG May Contain GPS Data: How EXIF Metadata Works and How to Strip It Before Sharing

Pixels and metadata are different things

What is EXIF?

Why developers should care about GPS metadata

When metadata should be preserved

Photography workflows

Scientific or field data

Asset-management systems

Forensic workflows

What happens with `fetch()`

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

Why `scale` matters