Initializing... drag & drop files here
Supports: 3GPP
.3gpp is the mobile container the 3rd Generation Partnership Project defined for GSM-era handsets; AVI is the RIFF-based container Microsoft shipped with Video for Windows in 1992. Converting between them is a compatibility move, not a quality move: it exists because a lot of Windows-side software — VirtualDub-derived editors, capture and analysis tools, older set-top hardware — will happily open an .avi and flatly refuse a .3gpp. This page covers what each format actually is, what the re-encode does to your footage, and when a different target would serve you better.
| Property | Value |
|---|---|
| Defined by | 3rd Generation Partnership Project, specification TS 26.244 |
| First published | April 2003 |
| Base format | MPEG-4 Part 12, the ISO base media file format (ISO/IEC 14496-12) |
| Video codecs it carries | H.263, MPEG-4 Part 2, H.264/AVC |
| Audio codecs it carries | AMR-NB, AMR-WB, AMR-WB+, AAC-LC, HE-AAC v1 and v2 |
| Media types | video/3gpp, audio/3gpp |
| File extensions | .3gp and .3gpp — two spellings of one format |
| Designed for | Capture, MMS, and streaming on GSM and UMTS handsets |
| Close relative | .3g2 (3GPP2), the CDMA2000 variant with a partly different codec list |
| Property | Value |
|---|---|
| Introduced by | Microsoft, November 1992, as part of Video for Windows |
| Base format | RIFF — a chunked container, with hdrl, movi, and an optional idx1 index |
| Extended by | OpenDML (AVI 2.0), published by the Matrox OpenDML group in February 1996 |
| Video codec written here | H.264 by default; MPEG-4, Xvid, DivX, MJPEG, MPEG-2 and others are selectable |
| Audio codec written here | MP3 by default |
| Payloads common in the wild | MPEG-4 ASP via DivX or Xvid, Indeo, Microsoft Video 1, run-length encoding |
| Structural gaps | No standardized timecode, no in-container subtitles, no aspect-ratio field in the original spec, and an index designed before frames could reference future frames |
| File extension | .avi |
| Still worth choosing when | A Windows editor, capture tool, or legacy player rejects modern containers |
.3gpp clips. Batch conversion is supported, so a folder of old phone videos can run as one job with identical settings..avi. Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.There is no shortcut path here. AVI cannot simply adopt a 3GPP video track the way a modern container sometimes can, so the source is fully decoded and re-encoded into the codec you chose, and the AMR or AAC soundtrack is re-encoded to MP3. That means one additional generation of lossy compression on footage that was already compressed hard for a mobile network. The practical consequences are worth stating plainly: the picture will not get sharper, the frame size stays whatever the phone recorded unless you deliberately change it, and the resulting AVI is usually larger than the .3gpp it came from, because 3GPP was tuned for scarce 3G bandwidth and AVI carries neither that tuning nor a compact index.
Choose AVI when a specific piece of software demands it. If the destination is a modern phone, browser, smart TV, or editor, 3GPP to MP4 is the better target — smaller at the same quality, and supported essentially everywhere.
.3gpp the same format as .3gp?Yes. Both extensions name the same container defined in 3GPP TS 26.244 — identical structure, identical codec set, identical metadata boxes. .3gp is the far more common spelling in the wild, and .3gpp shows up mostly from desktop software and email clients that expanded the name. This page accepts .3gpp; if your file uses the shorter form, use 3GP to AVI and nothing else changes. The .3g2 extension is a genuinely different thing: it is 3GPP2, built for CDMA2000 networks, not just an alternate spelling.
H.264 is the default and the right answer for anything written this century — VLC, MPC-HC, ffmpeg-based tools, and current editors all handle H.264-in-AVI. Choose MPEG-4 Part 2, Xvid, or DivX only when you are targeting hardware or software from the DivX era that will not decode H.264: standalone DVD players marked "DivX Certified", older set-top boxes, and some capture-card utilities fall into that category. Picking an older codec costs you compression efficiency, so the file gets larger for the same visual quality.
MP3 is what AVI's ecosystem standardized on, and it is what legacy Windows players and DivX-era hardware expect to find in a .avi. Your 3GPP soundtrack is most likely AMR-NB — a narrowband speech codec limited to roughly 200–3,400 Hz — or AAC-LC on later handsets, and either one is decoded and re-encoded to MP3. MP3 preserves what the source captured but cannot restore bandwidth the phone never recorded, so an AMR-sourced clip will still sound like a phone recording. One structural quirk worth knowing: AVI's audio interleaving was never designed for variable-bitrate MP3, which is part of why AVI audio sync problems became folklore.
No, and it cannot. The phone encoded the picture at a small frame size with H.263 or MPEG-4 Part 2 at a low bitrate, and re-encoding those decoded frames adds a compression generation rather than removing one. If you raise the resolution in the Video resolution section you get more pixels, not more detail — the encoder simply interpolates what is already there. AVI is worth choosing for compatibility with a specific tool; it is never worth choosing as a restoration step.
.3gpp file?Two reasons stack up. First, 3GPP files were engineered to be tiny so they could cross a 3G network or fit an MMS size cap, using aggressive inter-frame compression and speech-grade audio at a few kilobits per second. Second, AVI adds per-chunk RIFF overhead and an index, and the MP3 soundtrack alone typically runs at a higher bitrate than the AMR track it replaced. The output is normally larger even when it looks identical. If size matters more than Windows compatibility, use 3GPP to MP4, or shrink the result afterwards with Compress AVI.
The original 1992 specification's index structure imposes a practical 2 GB ceiling, which is why long captures from that era were split into multiple files. The OpenDML extension published in February 1996 lifts it by chaining additional index segments, and modern writers use OpenDML by default — but some legacy players and capture utilities still stumble on the extended index. In practice this is a non-issue for this conversion: a .3gpp phone clip decoded and re-encoded will not come anywhere near 2 GB unless it is hours long.
No. AVI has no standardized subtitle or chapter track — subtitles are conventionally shipped as a separate .srt beside the video or burned into the picture, and the container has no chapter concept at all. It also has no standardized timecode field, which is why post-production workflows moved off it. A .3gpp phone recording rarely carries either of these to begin with, but if you are converting something that does and you need to keep them, an MKV or MP4 target preserves them and AVI will not.
Files are uploaded over an encrypted connection and processed on our servers. They are deleted automatically after a few hours, and they are never shared, indexed, or made public. There is no sign-up and no watermark on the output. Nothing about the conversion depends on your machine's speed — the decode and re-encode happen server-side, so a long clip on a slow laptop converts just as quickly as on a fast one; the only part that scales with your connection is the upload itself.