No. The file is read by the page itself and encoded with a WebAssembly build of FFmpeg running on your device. Nothing is sent to a server, nothing is stored, and the download comes straight out of browser memory.
Five files per batch, 500 MB in total. The real ceiling is browser memory, since the encoder needs room for the decoded frames and the growing output, so a very large 4K file on a phone with little free RAM will be slower or may fail where the same file works on a desktop.
Target size is reached by calculating a bitrate from the duration and spending that budget, so the encoder lands close to the number rather than on it. Short clips and footage with a lot of motion can miss by a few percent either way. The estimate shown before the run comes from the source resolution and duration, so treat it as a guide.
Both. Set a start and an end time and only that range is encoded. Subtitles can be burned into the picture, which works in every player, or copied as a separate track, which keeps them selectable but needs MP4 or MKV and a player that understands them.
Yes, within the pairs that make sense. MP4 takes H.264, H.265 or AV1, MOV takes H.264 or H.265, WebM takes VP9 or AV1, and MKV takes H.264, H.265 or VP9. The tool hides combinations that players cannot open, so you never get an unplayable file.
29 containers, including MP4, MOV, M4V, MKV, WebM, AVI, FLV, 3GP, MPEG, VOB, OGV, IVF and raw H.264, H.265, VP9 and AV1 streams. MPEG-TS files from camcorders, GIF, ASF, WMV, DV and MXF are refused with a message instead of being queued, because the browser engine cannot read them reliably.