Split any file into parts that fit

Put the parts back together

This is the other half of the job, and it runs right here. Drop every part on the box below — in any order, straight out of your downloads folder — and the page reads the counter in each filename, glues the pieces back in sequence with one new Blob([…]), and hands you the original file. That is the part that normally forces the person receiving the files to install something: 7-Zip, Keka, a Discord plugin. Here, nobody installs anything at either end.

🔒 The rejoin is new Blob([…]) and the check is crypto.subtle.digest('SHA-256', …) — both are browser APIs, both run in this tab. Your files never leave your device, in either direction. Open your Network tab first if you like: rebuilding a file makes no request at all.

Why the numbers in the filenames matter

Every part is named yourfile.zip.part-003-of-012, and those two numbers are the entire mechanism. The counter is zero-padded to a fixed width on purpose: part-003-of-012 sorts after part-002-of-012 in a plain alphabetical listing, where an unpadded part-3 would sort between part-29 and part-30 and silently rebuild a corrupted file. The rejoin box above reads those numbers rather than the order you happened to select the files in, so dropping them backwards or in three separate goes makes no difference to the result.

Because every part except the last one is exactly the same size, the page can also sanity-check the pieces against each other before it glues anything: a part that came down short, or one that is somehow larger than the rest, is caught and named before you waste time on a file that will not open.

The four ways a pile of parts goes wrong

Each of these gets its own sentence on screen, naming the specific file or number involved — never a generic failure notice:

• A part is missing. The page says which index is absent and spells out the exact filename to ask the sender for. A split carries no redundancy, so 11 of 12 parts rebuilds nothing.
• A part is there twice. Usually because a browser wrote notes.zip.part-002-of-005 (1) rather than overwriting an earlier download. That is recognised as a duplicate of part 2, not mistaken for a mangled name.
• The parts come from two different files. Dropping a folder that holds two splits at once is caught, both original filenames are named, and you are told to do one file at a time.
• A part was renamed in transit. Some chat clients rename attachments they do not recognise, and a client that strips the .part-NNN-of-NNN suffix takes the order with it. The page names the renamed file and the exact name to restore. Discord itself does not rename attachments, so this mostly bites when the parts travel through something else on the way.

How you know the rebuild worked

A file that is one byte wrong usually looks fine until the archive refuses to open, so guessing is not good enough. When you split a file, this page shows you its SHA-256 — a 64-character fingerprint of the exact bytes. When you rebuild one, it shows the SHA-256 of the result. If the two strings match, the file you have is the file that was sent, and nothing else could produce that match. Paste the sender's fingerprint into the box above and the comparison is done for you; otherwise the two are printed in groups of eight characters so they can be checked by eye.

The hash comes from crypto.subtle, the hashing built into your browser — no library is downloaded and nothing is sent anywhere to compute it. It has one honest cost: crypto.subtle has no streaming mode, so the whole file has to sit in memory at once to be hashed. Below a few hundred megabytes that is instant and happens automatically; above it the page asks first with a button rather than freezing your tab, and the rebuilt file downloads either way.

If you would rather use a terminal

The shell one-liners still work and always will — parts are plain byte ranges, so concatenating them in order is the rejoin. They are no longer the only route, just a faster one if you already have a prompt open. On macOS or Linux, in the folder holding the parts:

cat 'project.zip'.part-* > 'project.zip'

On Windows, in Command Prompt (cmd.exe, not PowerShell — copy in PowerShell is an alias for Copy-Item and does not take /b):

copy /b "project.zip.part-*" "project.zip"

Both rely on the shell expanding part-* in name order, which is the same zero-padding trick described above. The split tool fills your real filename into both commands the moment it has a plan, so you can copy the exact line rather than editing an example. Neither command checks anything: if a part is missing or duplicated, cat will happily write a broken file and say nothing, which is the one thing the box above does better than a terminal.

What splitting actually does — and what it doesn't

smallcord's other four tools all do the same thing in different ways: they re-encode a file so that fewer bytes carry the same picture or sound. That answer does not exist for an archive, a document, a database or a save file. Re-zipping a ZIP buys you nothing — the redundancy is already gone — and there is no "quality" knob on a spreadsheet you could turn down. What is left is arithmetic: cut the bytes into N pieces that each fit, send the pieces, put them back.

• Nothing gets smaller. A 47 MB file split at 20 MB is three parts totalling 47 MB. You are moving the same bytes through a smaller door, three trips instead of one rejected trip.
• The parts are raw byte ranges, not archives. Part 3 of a video is not a playable video and part 2 of a ZIP will not open in any unzipper. Only the rejoined whole is usable — which also means nothing but the complete set is worth keeping.
• Every part except the last is exactly the limit. Part 1 through N−1 are byte-for-byte the size you picked; the last part is the remainder, which is usually much smaller. The page prints the exact byte offsets of every part before you download anything.
• Your recipient still has a step to do. Not an install and not a command any more — they open the rejoin box on this page and drop the whole set on it — but they do have to end up holding every part, and a split carries no redundancy, so one attachment that never arrived means nothing rebuilds. If the parts are going somewhere they might get separated, a file-host link is the kinder option and we would rather say so than pretend otherwise.
• The fingerprint has to travel separately. The rejoin is verified: this page shows a SHA-256 of your original file and of the rebuilt one, and a matching pair means the rebuild was byte-perfect. What it cannot do is check itself. The fingerprint has to reach your recipient by some other route — pasted into the chat next to the parts is enough — because a checksum shipped inside the same damaged set of files would be just as damaged.

The split maths lives in assets/split-plan.js, a pure module with no DOM and no I/O, and it is golden-vector tested in Node before it is ever wired to this page: contiguous ranges with no gaps or overlaps, the last part ending exactly at the file's final byte, and no phantom empty part when the size divides evenly. The page you are reading only asks that module questions and paints the answers.

How the parts are named

A part filename has to survive a downloads folder, a chat client and a sort, so the shape is deliberately boring: your original filename, extension and all, kept verbatim and in front, then the counter. holiday.mp4 split into twelve parts becomes holiday.mp4.part-001-of-012 through holiday.mp4.part-012-of-012. archive.tar.gz keeps both extensions.

Two decisions in that pattern are worth explaining. The original name stays in front so a human glancing at a downloads folder can see what they are holding, and so every part of one file sorts next to its siblings. The counter is zero-padded to at least three digits — widening automatically if a split genuinely needs more than 999 parts — so that an alphabetical sort is also the rejoin order, which is what makes the one-line cat and copy /b commands safe.

Filenames containing a slash or a control character are refused rather than quietly rewritten: a rewritten name means something different to the filesystem than what you saw, and that is exactly the kind of silent difference that turns into a corrupted rejoin. If you hit that, rename the file and choose it again.

When splitting is the wrong answer

If your file is a video, a GIF, an image or an audio recording, compress it instead. A 60-second 1080p screen capture that arrives as 120 MB is not six uploads and a rejoin problem; it is a bitrate problem, and smallcord will re-encode it in your browser down to a single file that fits. Splitting media should be your last resort, because you are handing someone six files they cannot even preview.

Go to Video for clips and screen recordings, GIF for animated GIFs (they become a silent MP4 or WebM, typically 5–20× smaller), Image for photos and screenshots, and Audio for voice notes and recordings. The home page has a table matching what you have to the right tool, and Privacy spells out exactly what this site does and does not do with your files.

Splitting is also the wrong answer when the part count gets silly. Twenty parts is a lot of attachments to post and a lot of files for someone to keep in order; the page says so when a plan crosses that line. Above the planner's own hard ceiling it refuses outright and tells you why, rather than trying to queue up a hundred thousand downloads and freezing your tab. If a 2 GB file will not fit any tier you have, the honest options are a file host link or a lower-resolution export, not two hundred attachments.