File Splitter
Cut a file into parts small enough to send, and hand over the commands that put it back together.
Drop the file to split
It is sliced in this page. Nothing is uploaded.
Sizes are balanced to within a byte of each other.
- Size
- —
- Parts
- —
- Each
- —
- SHA-256
- —
The rejoin does not need this page
The download includes rejoin.bat for Windows and rejoin.sh for
macOS and Linux, both using commands already on those machines. Parts are raw byte ranges,
so copy /b or cat rebuilds the file exactly.
Everything here runs on your device. Nothing you enter is uploaded or stored.
Some files are simply too large for the pipe you have to push them through. A mail attachment ceiling, an upload form that rejects anything over 100 MB, a USB stick formatted as FAT32 that will not accept a single file above 4 GB. Splitting is the plain answer, and it takes seconds. What takes longer is making sure the file comes back out the other end.
How to use it
Drop the file in. Choose a part size — the presets cover the common walls, from a 25 MB mail limit to just under the FAT32 per-file ceiling — or switch to a part count if you would rather say “five pieces” and let the sizes fall out. The plan appears immediately, listing every part with its size and its byte offset, so you can see what you are about to produce before you produce it. Then download.
Rejoining is the hard half
The person on the other end is not going to visit a website to reassemble your file. They might not be able to. That assumption shapes the whole tool, which is why the download contains two rejoin scripts written for commands that already exist on the machine receiving them.
rejoin.bat uses copy /b, built into every Windows installation since DOS. rejoin.sh uses cat, present on every macOS and Linux system ever shipped. Both list the parts explicitly rather than using a wildcard, because wildcard expansion order is not guaranteed and a rejoin in the wrong order fails quietly rather than loudly. Both are readable — anyone suspicious of running a script can open it and see that it does exactly one thing.
The hash covers the whole file, not each part
Computing the SHA-256 is optional and worth doing whenever the file matters. The value goes into the manifest and into both scripts as a comment, next to the command that checks it — certutil -hashfile on Windows, shasum -a 256 on macOS, sha256sum on Linux.
Hashing the whole original rather than each part is a considered choice. A per-part hash answers “did this part arrive intact”, which is a question modern transfers rarely get wrong. A whole-file hash answers “is the rebuilt file identical to what was sent”, which covers a missing part, a wrong order, and a transfer that corrupted the bytes in a way a part-level check would pass. One number, and it either matches or it does not.
Part numbers are padded on purpose
Parts are named after the original file with a numeric suffix — holiday.mp4.001, holiday.mp4.002, and so on — padded to at least three digits and widening automatically past a thousand parts. That padding is the difference between a glob that works and a corrupt output, because unpadded numbers sort as text and put part 10 ahead of part 2.
Keeping the original name and extension inside the part name is deliberate too. It means the recipient can tell what they are looking at, and it means the rejoin scripts can name the output correctly without being told.
Everything comes down as one ZIP
The parts, the manifest and both scripts arrive in a single archive. This is not for tidiness. Browsers treat a burst of downloads as popup behaviour and block everything after the first, so a tool that fires forty individual downloads delivers one part and leaves you convinced it worked. One archive, one download, nothing lost.
What it does not do
It does not rejoin. Reassembly belongs on the machine holding the parts, using tools already installed there, and a script is a better answer than a web page for a task that has to survive being handed to someone else. It does not compress — see below. It does not encrypt, and it does not add error correction or parity, because both would change the byte ranges and break the one property that makes the rejoin trivial.
Which tool for which job
| You want to | Use |
|---|---|
| Get past a size limit on content that will not compress | This tool |
| Make a file smaller before deciding whether to split it | ZIP Creator |
| Open an archive someone sent you | ZIP Extractor |
| Find out what is taking up the space | File Size Analyzer |
| Check a file’s real type, hash or embedded data | File Metadata Viewer |
Nothing here is uploaded. The file is read through the browser’s File API, sliced with Blob.slice, hashed with Web Crypto and packaged in the page. Close the tab and no copy remains anywhere.
Questions
How does the person receiving the parts put them back together?
With a script that is already in the download, using a command their machine already has. On Windows they double-click rejoin.bat, which runs the built-in copy /b to chain the parts into one file. On macOS or Linux they run rejoin.sh, which is a two-line cat. Neither needs anything installed and neither needs this website. That matters more than it sounds — the most common failure of a file splitter is that the recipient never manages to reassemble anything, because rejoining required a tool they did not have or a page they did not trust.
Are the parts a special format?
No. Each part is a plain byte range of your original file with no header, no footer and no metadata added. That is a deliberate constraint rather than a simplification, and it is what makes the rejoin scripts so short. Because nothing is wrapped around the data, concatenating the parts in order reproduces the original file byte for byte — with the supplied script, with copy /b, with cat, or by dragging them together in any tool that appends. A proprietary part format would work equally well on the way out and leave the recipient stranded.
What is the SHA-256 for?
To prove the rejoin worked, which is the step that actually goes wrong. Per-part checksums only tell you a part survived transit, and transit is rarely the problem — the problems are a missing part, parts joined in the wrong order, or a transfer that mangled line endings. All three produce a file that looks plausible and is broken. One hash of the whole original catches every one of them. The manifest and both scripts carry the expected value alongside the command to check it, so verification is a copy and paste rather than a research task.
Why is there a limit on parts sorting correctly?
Because part numbers are padded to a fixed width, and that is not cosmetic. A splitter that names parts .1 through .12 will have them listed as 1, 10, 11, 12, 2, 3 by most file managers and by every shell glob, and a rejoin in that order silently produces a corrupt file. Padding to at least three digits — .001 through .012, widening automatically past a thousand parts — makes lexical order and numeric order the same thing, so a glob or a drag-select is safe.
Should I split a file, or compress it?
Compress first, then split only if it is still too large. If the file is text, source code, a database dump or a CSV, ZIP Creator will often halve it or better and the problem disappears. Splitting is the right answer when the content is already compressed — video, photographs, existing archives, disk images — because those will not shrink meaningfully and the only way past a size limit is to send it in pieces. The two tools chain cleanly in either direction.
Last updated