Webtoon Stitching and Splitting: Heights, Formats, Naming

Webtoon raws usually arrive as a pile of slices with uneven heights, cut wherever the platform happened to cut them, often straight through a speech bubble. Stitching joins them into one continuous strip so you can clean and typeset without seams; splitting cuts the finished strip back into files of a sensible size, on blank space instead of through artwork. This guide covers both, plus the height, format and naming choices that decide whether your release looks clean.

If you want to do it right now, the free webtoon stitcher stitches and smart-splits in the browser. Your files never leave your computer.

Why stitch at all?

Raw slices are cut for the platform, not for you

Platforms slice images for their own loading needs. The result is slices that vary in height, and boundaries that fall wherever the counter ran out: mid-panel, mid-face, mid-bubble.

Bubbles cut across two slices

This is the main reason. If a bubble is split between 004.jpg and 005.jpg:

• The cleaner cleans two half-bubbles separately, and the halves rarely match at the seam.
• The typesetter has to place one sentence across two files, guessing where the cut falls.
• A reader on a slow connection sees half a bubble while the next file loads.

On a stitched strip, that bubble is one object. Clean it once, typeset it once.

One piece is easier to work on

Panels that span several slices, long vertical effects, scrolling text: all of these are easier when you can see them whole. It is also easier to keep a chapter's work in one file per section than in thirty slices.

Release files should have sensible sizes

Raw slices can be tiny (a few hundred pixels) or huge. Neither is good for readers. Splitting a stitched strip lets you choose the size.

Where it fits in the workflow

A typical order:

1. Stitch the raw slices into one strip, or a few large sections.
2. Clean on the stitched pieces (cleaning guide).
3. Typeset on the same pieces (typesetting guide).
4. Split for release, on blank rows.

Some groups split right after stitching, so cleaners and typesetters work on files that already have good cut points. That works too. What matters is that every member of the chapter uses the same stitched and split set; a cleaner on one split and a typesetter on another produces files that do not line up.

How smart splitting works

A "dumb" split cuts every N pixels, no matter what is there. A smart split looks for a safe place near your target height:

1. Go to the target height (say 10,000 px).
2. Look at each pixel row near that point.
3. Find a row where every pixel is the same colour, or nearly so: blank background between panels, a flat gutter.
4. Cut there. If no safe row exists nearby, search further up or down within a tolerance, and only then fall back to a hard cut.

The settings you will see in most tools:

• Target height: where to start looking.
• Sensitivity / tolerance: how different the pixels in a row may be and still count as "flat". Too strict, and gradients or noisy backgrounds never qualify. Too loose, and the tool happily cuts through a light-coloured bubble.
• Search range: how far from the target it may move to find a safe row.

After any automatic split, scroll through the cut points. A cut through a pale bubble or a soft gradient sky is easy to miss in a file list.

The webtoon stitcher does this kind of split and avoids cutting through speech bubbles. Desktop tools such as SmartStitch, an open-source stitcher, follow a similar approach.

Choosing a split height

There is no universal correct height. These are the forces at play:

Too short (under ~3,000 px)	Too tall (over ~20,000 px)
Many files per chapter, more naming to manage	Large files, slow to load on mobile data
More cut points, more chances to cut through art	Some image formats and editors refuse the size
Readers see more loading gaps	Some mobile browsers downscale or struggle with very tall images

For most groups, a range of roughly 5,000 to 15,000 px per file is a comfortable middle. Within that range:

• Toward 5,000–8,000 px if your readers are mostly on phones, or the chapter has many large colour panels.
• Toward 10,000–15,000 px if the strip is mostly white space and you want fewer files.

Pick one target per series and keep it.

Hard limits to know

Some limits are fixed by the format or the software:

• JPG cannot exceed 65,535 px in either dimension.
• WebP cannot exceed 16,383 px in either dimension.
• Photoshop's PSD format is limited to 30,000 px per side; taller documents must be saved as PSB (Large Document Format).
• Browser-based editors and phone browsers have their own memory limits that depend on the device. A strip that opens on your desktop may fail on someone else's laptop.

For working files, this means stitching a whole 80,000 px chapter into one document is often a bad idea. Stitch into sections of a size every member's machine can handle, cutting on blank rows, the same way you would split for release.

Width normalisation

Raw slices from one chapter usually share a width, but not always. A mixed-width chapter shows up as panels that suddenly jump or shift sideways.

• Find the majority width and make that the chapter's width.
• Resize the odd ones to match, keeping proportions. Use a good resampling method (bicubic or Lanczos, depending on your software).
• Avoid upscaling the whole chapter just to make the width a round number. It adds file size, not detail.
• If a slice is narrower because it has a border or padding, crop or pad it instead of stretching the art.

Keep the same width across the whole series if you can. Readers notice when chapter 12 is suddenly wider than chapter 11.

JPG, PNG or WebP?

Format	Strengths	Weaknesses	Good for
PNG	Lossless, sharp text and lines	Large files for colour art	Working files, B&W, flat-colour strips
JPG	Small files for colour art, works everywhere	Lossy; blurs around text at low quality; 65,535 px limit	Release files for full-colour webtoons
WebP	Smaller than JPG at similar quality	16,383 px height limit; older tools may not open it	Release files, if your readers' platforms support it

Practical guidance:

1. Work lossless. Keep stitched and cleaned files as PNG or in your editor's native format until release.
2. Export once, at the end. Every lossy save loses a bit more. Never re-save a JPG you have already saved as JPG.
3. Check quality at text edges. Compression artefacts show first around text and line art. Export at a high quality setting, view at 100%, and lower it only while you cannot see a difference.
4. Stay under the format's limits. If your target height is 15,000 px, WebP is fine; at 18,000 px it is not.

File naming

Readers, tools and every team member sort files by name. Bad names break reading order.

• Zero-pad numbers: 001.png, 002.png … 010.png. Without padding, 10.png sorts before 2.png on many systems.
• Pad enough for the chapter: three digits is safe for almost any webtoon chapter.
• Name for order, not content: no "final", "v2", "fixed" in release filenames.
• Keep names stable across stages: if the cleaner hands over 004.png, the typesetter returns 004.png. Renaming mid-chapter loses track of which file is which.
• Avoid spaces and special characters that some servers or archive tools mangle.

Step-by-step: a typical chapter

1. Put the raw slices in one folder, named in order.
2. Check widths. Normalise outliers.
3. Stitch into one strip, or into sections a typical member's editor can open.
4. Smart-split to your working size (if your group splits before cleaning), then scroll every cut point.
5. Hand the set to cleaning and typesetting. Everyone uses the same files.
6. After QC, split for release at your series' target height, smart-split again, and check every cut.
7. Export once to the release format, with zero-padded names.
8. Open the release files in order on a phone and scroll the whole chapter.

Common mistakes

• Cleaning on raw slices. Half-bubbles cleaned twice with a visible seam.
• Different splits per team member. Files from the cleaner and typesetter do not line up.
• Cutting through pale bubbles or gradients. Tolerance too loose, or nobody checked the cut points.
• Exceeding format limits. A WebP over 16,383 px or a JPG over 65,535 px fails to save or is silently cropped by some tools.
• Re-saving JPGs. Blurred text and blocky gradients by the third save.
• Upscaling to a "nice" width. Bigger files, no better art.
• Unpadded names. Page 10 appears after page 1 in someone's reader.
• Never checking on a phone. That is where most webtoon readers are.

Checklist

• Widths checked and normalised
• Stitched pieces open on every member's machine
• Everyone works on the same split set
• Every cut point checked by eye
• Release height consistent for the series, within format limits
• Working files lossless; release exported once
• Zero-padded, stable filenames
• Chapter scrolled end to end on a phone

Tools

The free webtoon stitcher stitches slices and smart-splits on blank rows without cutting through speech bubbles, all in your browser. More free utilities are on the tools page. If your group tracks chapters in FansubPanel, upload the stitched set to the chapter once; the cleaner and typesetter then download the same files instead of each stitching their own.