Tired of uploading 40MB PNGs to your server and then slicing them (React + Canvas)

Krishna Kumar — Sat, 31 Oct 2026 04:38:24 +0000

As a digital comic artists, we all know , we love exporting massive files.

I run a small indie comic platform called ZealPlane and we were putting together chapters for our original series KARMA, G.O.D (unpublished) We’d often send over single vertical strips that were 1600px wide and 30,000px tall from Clip Studio Paint. even upto 45MB, just for a sinlge image.

You obviously, can't serve a 30,000px tall PNG directly to a mobile browser unless you want your reader's phone to catch fire. Webtoons and Tapas make you chop up long vertical strips into 800x1280 pieces so they lazy-load cleanly as the user scrolls down.

At first, Like many backend devs, I upload the file to a Node server, pipe it through sharp, zip up the slices, and send it back.

turned out to be not a great idea.

When you decode an uncompressed 1600x30000 RGBA image into memory on the server, it eats almost 200MB of raw RAM per request. It took was three or four people slicing chapters at the same time to spike our VPS memory and stall Nginx. Additionally, waiting 40 seconds just to upload a file on a slow connection and download the exact same pixels back felt super dumb.

So a few weeks ago, I ripped out the backend endpoint and rewrote our Webtoon Slicer to run 100% in the browser. Zero uploads, zero server costs, and it finishes in like 300ms.

Here are a few weird browser quirks I ran into while building it, in case anyone else is messing with huge images in React.

Don't use FileReader.readAsDataURL()

My first instinct was to read the uploaded file as a base64 string, stick it into an tag, and draw it onto a .

Don't do this with 40MB files. Base64 inflates the string size by ~33%, and decoding a massive image on the main thread completely freezes the React UI for two seconds.

Use createImageBitmap(file) instead. It takes the raw File or Blob directly from the file input and decodes it off the main thread.

export async function sliceStrip(file, targetWidth = 800, sliceHeight = 1280) {
// Decodes off-thread without base64 bloat
const bitmap = await createImageBitmap(file);

const scale = targetWidth / bitmap.width;
const totalScaledHeight = Math.round(bitmap.height scale);
const count = Math.ceil(totalScaledHeight / sliceHeight);

const results = [];

for (let i = 0; i < count; i++) {
const currentY = i sliceHeight;
const h = Math.min(sliceHeight, totalScaledHeight - currentY);

// Map back to the original unscaled image coordinates
const srcY = currentY / scale;
const srcH = h / scale;

const canvas = document.createElement('canvas');
canvas.width = targetWidth;
canvas.height = h;

const ctx = canvas.getContext('2d');
ctx.imageSmoothingEnabled = true;
ctx.imageSmoothingQuality = 'high';

ctx.drawImage(
  bitmap,
  0, srcY, bitmap.width, srcH,
  0, 0, targetWidth, h
);

const blob = await new Promise((res) => canvas.toBlob(res, 'image/png'));

results.push({
  name: `slice_${String(i + 1).padStart(3, '0')}.png`,
  blob,
  url: URL.createObjectURL(blob),
});

}

// Crucial: free the GPU texture immediately!
bitmap.close();
return results;
}

The 1px white line bug drove me crazy

Once we got this working, our artists noticed something super annoying. On dark fantasy panels—especially stuff with heavy black/purple gradients like you see in Solo Leveling: Ragnarok's vertical fight scenes—there was occasionally a tiny 1-pixel horizontal grey seam where two sliced images met on mobile screens.

Turns out, if an artist uploads an odd-width image (say 1240px wide) and you scale it down to 800px, srcY and srcH end up as floating-point decimals like 1984.3333px. When the HTML5 canvas samples sub-pixels along the very bottom edge of a crop, it blends the edge with empty transparent pixels, creating a faint semi-transparent border.

Forcing integer math on the source crop coordinates (or keeping the artist's source canvas at an exact multiple like 1600px -> 800px) killed the seam lines immediately.

Clean up your Object URLs or Safari will crash

One thing you forget when working in a React SPA: URL.createObjectURL(blob) stays pinned in browser RAM until the document unloads or you manually revoke it.

If an artist slices a 25-panel chapter, realizes they made a typo in a speech bubble, fixes it, and drops the file in again 4 times in a row, your tab is suddenly holding onto 100 uncompressed PNG blobs in memory. Mobile Safari will just hard-reload the tab without warning.

Whenever the user resets the tool or drops a new file, loop through the old state first:

useEffect(() => {
return () => {
slices.forEach((s) => URL.revokeObjectURL(s.url));
};
}, [slices]);

And don't forget bitmap.close() at the end of your slicing function. Garbage collection on ImageBitmap is notoriously lazy in Chromium.

Anyway, if you draw webcomics or just want to poke around with how it works in the browser, the tool is live here (no login or paywall or anything, it literally just runs in your tab): zealplane.com/tools/webtoon-slicer.

How are you guys handling large client-side image jobs? Has anyone played around with OffscreenCanvas inside a Web Worker for this yet, or is standard createImageBitmap fast enough for your use cases?

If you've ever worked with digital comic artists, you know they love exporting massive files.

I run a small indie comic platform called ZealPlane, and when we were putting together chapters for our original series KARMA, our artists would regularly hand over single vertical strips from Clip Studio Paint that were 1600px wide and 30,000px tall. Sometimes a single image was 45MB.

You obviously can't serve a 30,000px tall PNG directly to a mobile browser unless you want your reader's phone to catch fire. Platforms like Webtoon and Tapas force you to chop long vertical strips into 800x1280 chunks so they can lazy-load cleanly as the user scrolls down.

At first, I did what most backend devs do: upload the file to a Node server, pipe it through sharp, zip up the slices, and send it back.

Bad idea.

When you decode an uncompressed 1600x30000 RGBA image into memory on the server, it eats almost 200MB of raw RAM per request. All it took was three or four people slicing chapters at the same time to spike our VPS memory and stall Nginx. Plus, waiting 40 seconds just to upload a file on a slow connection and download the exact same pixels back felt super dumb.

So a few weeks ago, I ripped out the backend endpoint and rewrote our zealplane.com/tools/webtoon-slicer to run 100% in the browser. Zero uploads, zero server costs, and it finishes in like 300ms.

Here are a few weird browser quirks I ran into while building it, in case anyone else is messing with huge images in React.

Don't use FileReader.readAsDataURL()

My first instinct was to read the uploaded file as a base64 string, stick it into an <img> tag, and draw it onto a <canvas>.

Don't do this with 40MB files. Base64 inflates the string size by ~33%, and decoding a massive image on the main thread completely freezes the React UI for two seconds.

Use createImageBitmap(file) instead. It takes the raw File or Blob directly from the file input and decodes it off the main thread.

export async function sliceStrip(file, targetWidth = 800, sliceHeight = 1280) {
  // Decodes off-thread without base64 bloat
  const bitmap = await createImageBitmap(file);

  const scale = targetWidth / bitmap.width;
  const totalScaledHeight = Math.round(bitmap.height * scale);
  const count = Math.ceil(totalScaledHeight / sliceHeight);

  const results = [];

  for (let i = 0; i < count; i++) {
    const currentY = i * sliceHeight;
    const h = Math.min(sliceHeight, totalScaledHeight - currentY);

    // Map back to the original unscaled image coordinates
    const srcY = currentY / scale;
    const srcH = h / scale;

    const canvas = document.createElement('canvas');
    canvas.width = targetWidth;
    canvas.height = h;

    const ctx = canvas.getContext('2d');
    ctx.imageSmoothingEnabled = true;
    ctx.imageSmoothingQuality = 'high';

    ctx.drawImage(
      bitmap,
      0, srcY, bitmap.width, srcH,
      0, 0, targetWidth, h
    );

    const blob = await new Promise((res) => canvas.toBlob(res, 'image/png'));

    results.push({
      name: `slice_${String(i + 1).padStart(3, '0')}.png`,
      blob,
      url: URL.createObjectURL(blob),
    });
  }

  // Crucial: free the GPU texture immediately!
  bitmap.close();
  return results;
}

The 1px white line bug drove me crazy

Turns out, if an artist uploads an odd-width image (say 1240px wide) and you scale it down to 800px, srcY and srcH end up as floating-point decimals like 1984.3333px. When the HTML5 canvas samples sub-pixels along the very bottom edge of a crop, it blends the edge with empty transparent pixels, creating a faint semi-transparent border.

Forcing integer math on the source crop coordinates (or keeping the artist's source canvas at an exact multiple like 1600px -> 800px) killed the seam lines immediately.

Clean up your Object URLs or Safari will crash

One thing you forget when working in a React SPA: URL.createObjectURL(blob) stays pinned in browser RAM until the document unloads or you manually revoke it.

Whenever the user resets the tool or drops a new file, loop through the old state first:

useEffect(() => {
  return () => {
    slices.forEach((s) => URL.revokeObjectURL(s.url));
  };
}, [slices]);

And don't forget bitmap.close() at the end of your slicing function. Garbage collection on ImageBitmap is notoriously lazy in Chromium.

How are you guys handling large client-side image jobs? Has anyone played around with OffscreenCanvas inside a Web Worker for this yet, or is standard createImageBitmap fast enough for your use cases?

DEV Community: Krishna Kumar

Tired of uploading 40MB PNGs to your server and then slicing them (React + Canvas)

Don't use FileReader.readAsDataURL()

The 1px white line bug drove me crazy

Clean up your Object URLs or Safari will crash