Split large files for upload caps and merge the parts
Upload forms and mail servers enforce size ceilings. This page cuts a large file into chunks you can send, then merges those parts back into the original file.
Split oversized files into smaller parts for email limits, or merge chunk files back into one download.
Server processing — files deleted after job
Split or merge files
Split by chunk size (MB) or merge multiple parts in order.
Drop file to split
Select multiple part files (.part001, etc.)
Email-friendly parts
Split archives when providers cap attachment size (50MB, 25MB, etc.).
Ordered merge
Upload .part001, .part002, … files and rebuild the original binary.
Auto cleanup
Uploads are deleted from our servers immediately after your download completes.
Why upload caps force a split
Email gateways, ticket portals, and consumer cloud forms often reject a single attachment above a fixed size. Splitting the file into numbered parts lets you upload or mail each chunk under the cap, then reassemble on the other side.
Splitting does not compress. Each part carries a slice of the original bytes. If you need a smaller total size, compress first, then split only if the archive is still over the limit.
Agree on part size with the recipient before you send. Matching the portal’s stated maximum with a little headroom avoids rejected uploads.
- Choose split mode and a chunk size under the destination cap.
- Upload or send every part without renaming the sequence.
- On the other device, merge the parts in order to rebuild the file.
Split by chunk size
Pick a chunk size the destination accepts. Common caps sit at a few megabytes for older mail systems and higher for modern cloud forms. Read the error message when an upload fails; it usually names the limit.
The tool writes numbered parts from the original. Keep all parts. Losing one part breaks the merge.
Do not open part files as if they were the finished document. They are slices until merge completes.
Merge parts back into one file
Collect every part in one folder. Select them in the merge UI in the order the split created. Start merge and wait until the rebuilt file finishes downloading or saving.
Open the merged result before you delete the parts. Confirm size and that the file opens in its normal app.
If merge fails, check for a missing number in the sequence or a part that was truncated during transfer. Re-download that part and merge again.
Channels that force this workflow
Legacy mail servers, classroom portals, and some government upload forms still enforce low ceilings. Split-merge is the practical path when the other party cannot accept a cloud share link.
Chat apps may also reject large attachments. Sending parts in order with clear filenames helps the recipient sort them.
When both sides can use a modern drive link, prefer that for convenience. Use split-merge when the channel itself is the constraint.
Split versus compression and encryption
Compression reduces total bytes. Splitting only packages the same bytes into smaller packages. Try compression when the goal is a smaller single file. Split when the goal is multiple under-cap uploads.
Encrypt before you split if the parts will travel over channels you do not trust. Encrypting after a split means managing many keys or many encrypted blobs.
Repair tools help when a transfer corrupts a part. They do not replace a missing part.
Browser tool behavior and cleanup
Use the split and merge controls on this page as the live tool presents them. Processing follows the browser utility flow for the files you select. Download outputs when the job completes.
Leave the tab open until writes finish. Partial downloads look complete until merge or open fails.
After a successful merge, archive or delete the parts so you do not mix old sequences with a new split later.
Checksums and trust after a merge
When the sender publishes a checksum for the original, hash the merged file and compare. Matching hashes mean the rebuild matches the source bytes.
If hashes differ, re-transfer the parts and merge again. Do not assume a slightly different size is “close enough” for installers or disk images.
Name merged outputs after the original project file so recipients know they can discard the part set.
Write the part count in the email or chat that delivers the set. Recipients can count files before they merge and catch a missing attachment early.
For recurring deliveries, keep a short checklist: chunk size, part naming pattern, merge order, and checksum method. That checklist prevents each transfer from reinventing the process.
If a portal allows only one upload at a time, upload parts in order and wait for each success message before starting the next. Parallel uploads into picky forms often scramble filenames.
Keep a simple log of which part sets you already merged so you do not rebuild an old package by mistake.
After you finish, open the result on your device, move keepers into a folder you control, and only then close this tab. That sequence keeps half-written files and lost downloads out of your next session.
If something fails, change one variable at a time: the input file or URL, the output format choice, or the network you are on. Note what changed so the next attempt is a measured test rather than a random retry.
Questions about split and merge
Does splitting compress my file?
No. Splitting cuts the file into sized chunks. Compress first if you need a smaller total size.
What chunk size should I use?
Stay under the upload or email cap for your destination, with a little headroom. Match what the recipient expects.
What if one part is missing?
Merge cannot rebuild the original. Re-send the missing part and merge the complete set.
Should I encrypt before or after splitting?
Encrypt the whole file first when parts will travel over untrusted channels, then split the encrypted output.
Can I open a part file on its own?
No. Parts are slices. Merge them to restore a usable file.
How do I confirm the merge worked?
Open the merged file in its normal app, check the size, and compare a checksum when the sender published one.