Loom's upload documentation states the file it wants in one line: "We recommend exporting your video using the media specifications in the above table (H.264/AAC to . MP4 file.)" The table it points at describes uploaded videos as "Codec: H.264" for video and "Codec: AAC, 48kHz" for audio.
If your source already holds H.264 video and AAC audio in some other container, you do not have to re-encode anything to produce that file. You need a remux — a container swap that copies the existing streams packet for packet. It is one FFmpeg command, it finishes in seconds on a file that would take an hour to re-encode, and FFmpeg's own documentation says it costs nothing in quality.
The command
ffmpeg -i input.mov -c copy output.mp4That reads input.mov, writes output.mp4, and leaves both streams exactly as they were. Nothing is decoded, so nothing is degraded and nothing about the picture changes.
What each part does
-i input.mov— the source file. The source container does not have to be one Loom accepts; the output is what gets uploaded.-c copy— the whole trick. FFmpeg's documentation defines this mode directly: "The simplest pipeline inffmpegis single-stream streamcopy, that is copying one input elementary stream's packets without decoding, filtering, or encoding them." And on what it is for: "Streamcopy is useful for changing the elementary stream count, container format, or modifying container-level metadata. Since there is no decoding or encoding, it is very fast and there is no quality loss."output.mp4— the container you are targeting. MP4 is what Loom's recommendation names. For how FFmpeg decides which muxer to use for a given output, check the official FFmpeg documentation.
Read the scope of that second quote literally, because it is the part that decides whether this command helps you at all. Stream copy changes the container format, the stream count, and container-level metadata. That is the list. It does not change the codec, the resolution, or the frame rate — there is no decoding step in which such a change could happen.
So the one thing a remux cannot do is make a non-H.264 video into an H.264 video. If your source is VP9 in a WebM file, -c copy into an .mp4 gives you an MP4 that still contains VP9 — a file whose extension matches Loom's recommendation while its contents do not. Remuxing is a fix for the wrapper, not for the encoding.
Variations
Target MOV instead of MP4. Loom's media specification table for uploaded videos reads: "Supported containers: MV, AVI, WEBM, MP4, MOV (Up to 4GB)". MOV is on that list, so a remux to .mov is equally valid if that suits your workflow:
ffmpeg -i input.mkv -c copy output.movKeep only one video and one audio stream. Multi-track sources — screen recorders that write system audio and microphone separately, camera files with a timecode track — often carry more streams than you want in the upload. -map selects them explicitly:
ffmpeg -i input.mov -map 0:v:0 -map 0:a:0 -c copy output.mp4Be careful with this one. FFmpeg's documentation warns that the flag is all-or-nothing: "When -map is used, only user-mapped streams are included in that output file, with one possible exception for filtergraph outputs." Anything you forget to map is silently dropped.
Re-encode only the audio. Loom's KB names one specific upload failure that a container swap cannot touch: "There are times when an underlying property of your video is not supported (like the number of audio channels is too high) and this can only be fixed by running the media through Handbrake." Changing a channel count requires decoding and re-encoding the audio, which is exactly what stream copy refuses to do. You can still copy the video:
ffmpeg -i input.mov -c:v copy -c:a aac -ac 1 output.mp4The video here is still a straight copy, so FFmpeg's no-quality-loss guarantee holds for the picture — but not for the audio, which is genuinely re-encoded. For the exact semantics of the audio options, check the official FFmpeg documentation.
If you would rather not install FFmpeg
For a single QuickTime file that needs to become an MP4 before an upload, the container swap can happen in your browser instead:
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
The file is read from disk, converted locally and handed back, so nothing is uploaded on the way to fixing an upload. What you give up is control: MOV to MP4 gives you a standard MP4, not a per-stream mapping switch. When you need -map, or you are batching fifty files, the command line wins. The rest of the converters live under all Clapr tools.
Troubleshooting: when a remux will not save you
A remux fixes exactly one class of problem. Here is what Loom documents as the other classes, so you can tell them apart before you spend an upload on it.
| Symptom | Loom's own wording | Can a remux fix it? |
|---|---|---|
| Upload option missing entirely | Uploading "is only available to users on Loom's Loom's Business, Business + AI or Enterprise plans" | No |
| "Failed to process" | "This most often occurs because the file is over 4 GB, its frames per second are over 60, or its resolution is over 4096 x 2160." | Only if none of the three apply |
| File is 6 GB | "Loom limits uploads to 4 GB or 12 hours, whichever is less." | No — see below |
| Container not accepted | "Supported containers: MV, AVI, WEBM, MP4, MOV (Up to 4GB)" | Yes |
On size: stream copy writes the same packets into a new wrapper, so it is not a route under 4 GB. Getting there means re-encoding. Same for the other two thresholds Loom names — over 60 fps and over 4096 x 2160 both describe the encoded streams, which -c copy deliberately leaves alone.
On the plan gate: Loom also notes "Uploads are not available for Business + AI Trials", and the Business plan FAQ adds "Please note the Upload feature is temporarily unavailable for Business Trial users." No command line fixes an account state. The full list of rejection causes is in Loom's "Failed to process" upload errors.
On stalled uploads: Loom's troubleshooting KB asks for "an upload speed of at least 5 Mbps", and notes that uploads continue in the background: "Your videos will keep uploading even if you leave the upload modal. The uploads only stop if you select cancel."
FAQ
Does remuxing reduce video quality? No. FFmpeg's documentation states it outright for stream copy: "Since there is no decoding or encoding, it is very fast and there is no quality loss." The packets in the output are the packets from the input.
Will remuxing get my file under Loom's 4 GB upload limit? No. A remux rewrites the container around the same streams. Loom's ceiling is "4 GB or 12 hours, whichever is less" — reaching it requires re-encoding, not a container swap.
Can I upload an MKV to Loom?
Loom's accepted list is "MV, AVI, WEBM, MP4, MOV (Up to 4GB)", and .mkv is not one of those five entries. Remux it to MP4 or MOV first. Note that the first entry really is written MV on Loom's pages — the same list appears verbatim on three of them — so treat it as printed rather than assuming what it stands for. More on that list in Loom's supported upload formats.
Do I need to remux a video I downloaded from Loom before re-uploading it? Loom states that "All videos downloaded from Loom will be in a .MP4 format", which is already an accepted container. Loom describes the download's encoding as "similar to the RAW media recorded" — similar, not identical — so if a re-upload is rejected, check it against the three thresholds rather than assuming the container.
Loom still rejects the file after remuxing. What now? Loom's own advice at that point is to re-encode rather than repackage: "If the file you want to upload to Loom is not supported or you believe it should be supported but is being rejected, try running your video through Handbrake." That is Loom's recommendation verbatim, and it is aimed at properties a remux cannot reach — codec, frame rate, resolution, audio channel count.
Loom quotes are from Atlassian's Loom help centre — the video encoding settings, upload and upload-failure pages — checked 16 September 2026. The FFmpeg quotes are from the FFmpeg documentation, sections "Streamcopy" and "Main options". More command-line write-ups live in our ffmpeg guides.
