When to use it
When a platform displays a long image as an ordinary image, the more extreme the aspect ratio the worse it fares: a 1080×6000 image is squeezed into a very narrow strip in the feed and the text is almost unreadable in the thumbnail. Cut it into 6 slices that are each close to square and the user sees 6 images with a normal ratio.
A screenshot that is itself one long post — a chat log, order details, course notes — also suits this treatment: sending it directly forces the other person to keep zooming in and dragging sideways, so cut it into 3 to 5 pieces of about one screen height each, and the page order becomes the reading order.
How to choose the settings
- Choose slice height by platform first: platforms for multi-image posts often favour a near-square ratio, so at 1080px wide, 1080–1440px (1:1 to 3:4) is steadiest; text-heavy long images such as chat logs, code and tables suit taller slices, 1500–2000px each, where the text is not shrunk so small. Taller slices mean fewer pieces and more information per image but smaller text; shorter slices mean more pieces and more page turns.
- For images with sections, use by count and cut 3–9 slices so each one matches a section; for a plain long image with no sections, use by height, since the numbers are easy to remember and easy to map back to the original.
- The gap between slices is adjustable from 0–60px, and 8–24px is enough in practice. It does two things: it makes the break visible when adjacent slices sit side by side, and it leaves a little buffer for a platform's preview cropping and rounded corners. Above 40px, every image in the feed loses a strip at the end.
- Turn on padding for the last slice only when the platform or layout requires every slice to be exactly the same size; the added rows are solid background colour with no real content.
- Output format: choose PNG for screenshots and text; choose JPG for social platforms only, where quality 0.92 is the balance between size and appearance, below 0.85 text edges show colour noise, and the platform compresses it again after receiving it, so the two losses add up.
Compared with other approaches
Slicing itself creates no new pixels: a section of the original is moved 1:1 onto a canvas of the same size, source and target dimensions are identical, and without scaling there is no interpolation blur. The slice height is rounded rather than divided exactly so that the slices sum to exactly the original height — exact division drops the remainder rows, while rounding only spreads those rows across a few slices. This is geometry only: when you output JPG, each slice is lossily encoded again, so the bytes differ from the original, and repeated slicing and saving accumulates loss; use PNG when you need strict fidelity.
Once you enable the white border or the padding, it is no longer identical pixel for pixel: the exported image has a few extra rows of solid colour, the pixel grid shifts down as a whole, and the stitched-back image is taller, with rows that did not exist in the original. This is not a defect but the definition of those two features, and you can restore it by trimming the extra white strip at the bottom of each slice to the original slice height.
Compared with Photoshop slicing and long-image screenshot apps: those tools let you set each slice's range freely with guides, which suits making dozens of differently sized images at once; we can only split vertically into equal parts, with no custom start and end per slice and no horizontal cutting. Compared with online slicing sites: most services upload the image to a server first and return the result, so the image is copied in full onto someone else's disk, which is unsuitable for chat logs, orders and ID documents; here everything is done locally in your browser, the image never enters any network request, at the cost of being limited by this machine's memory and canvas limits, and slower the weaker the machine and the more slices there are.
Additional Q&A
How many slices is right, and what is the trouble with too many?
3–9 slices is the usual range. Beyond 9 slices the user has to swipe many times, and most platforms cap a single post at 9 images, so the rest can only go in a second post and the reading order breaks. The more slices there are, the shorter each one is, and the more it is enlarged on the detail page, so the text looks blurrier.
Why is the total file size larger than the original after slicing into 6 pieces?
Each slice is an independent file carrying its own image header; each PNG slice stores its own compressed blocks, and each JPG slice is quantised separately. The extra cost is container overhead that grows linearly with the number of slices, so make fewer slices or switch to JPG if you want it smaller.
If I add a white border, will the platform still crop my content?
A white border only lowers the probability, it is not insurance. A platform's preview cropping, rounded corners and scaling are outside the tool's control; a white border gives text near the edge a little more room, but if the platform force-crops a 3:4 image to a square, what is cut away is still original content.
With many slices it gets slow halfway through and seems stuck — what should I do?
That is this machine encoding slice by slice: a 1080×20000 image cut into 20 slices means 20 full encoding passes, which visibly stutters on a weaker machine. You can raise the slice height to reduce the count, or switch to JPG. If you change parameters midway you must click start again, and the slices already generated are discarded.