Initializing... drag & drop files here
Supports: AIF, AIFF
AIFF and AIFC (AIFF-C) are the same Apple container family, not rival formats. AIFF (1988) holds only uncompressed big-endian PCM; AIFC (1991) is the same container with one addition — a compression-type field in the COMM chunk that lets the audio chunk name a codec instead of assuming raw PCM. This converter writes AIFC with PCM 16-bit Big Endian by default, which is the exact encoding AIFF already uses. So the honest short answer: convert to AIFC only when a downstream Mac or pro-audio tool specifically wants the .aifc structure. If you want a genuinely smaller file, the codec change is what matters — see the options below.
| Property | AIFF | AIFC (AIFF-C) |
|---|---|---|
| Introduced | Apple, 1988 (EA IFF 85-based) | Apple, 1991 (AIFF-C extension) |
| Container | FORM / IFF chunked | Same FORM / IFF container |
| COMM chunk | No compression field | Adds a compression-type field + FVER chunk |
| Audio payload | Uncompressed PCM only | Named codec: NONE (PCM), alaw, ulaw, ima4, fl32/fl64, sowt |
| Default here | PCM 16-bit Big Endian | PCM 16-bit Big Endian (same bytes, re-tagged) |
| Byte order (default PCM) | Big-endian | Big-endian (sowt variant is little-endian) |
| File size at default | Large (~10 MB/min CD stereo) | Identical at default; smaller only with a lossy codec |
| Lossless? | Always | Yes with NONE/PCM/float; lossy with A-law, mu-law, IMA |
| Best for | Maximum AIFF compatibility, editing | Tools that require the .aifc identifier or an in-container codec |
A common misconception (repeated by many converter sites) is that AIFC "compresses without quality loss." That is only true for the lossless codecs. With the default PCM codec there is no compression at all, and the A-law / mu-law / IMA codecs are genuinely lossy.
.aifc structure or the FVER/compression-type field that only AIFF-C carries.fl32/fl64) for a mastering chain, which plain AIFF cannot wrap.Not pointless — but be clear about what you get. With the default PCM 16-bit Big Endian codec the audio data is byte-for-byte the same as your AIFF; only the container identifier changes to AIFF-C and a compression-type field is added to the COMM chunk. That matters when a tool specifically checks for the .aifc form or the FVER chunk. If nothing downstream requires AIFF-C, you gain nothing and can stay on AIFF.
Lossless if you keep the default codec (PCM 16-bit Big Endian) or pick another PCM/float codec — that is a container and tagging change only, with no audio discarded. It becomes lossy if you switch to A-law / mu-law (8-bit companded, ~2:1) or IMA ADPCM (4-bit, ~4:1). Pick a lossy codec only when you specifically need the in-container size reduction.
Only if you choose a compressing codec. The default carries uncompressed PCM, so the AIFC is essentially the same size as the source AIFF. For a real reduction you either select mu-law/A-law/IMA inside AIFC (lossy), or convert to a modern format. For genuinely smaller lossless files use AIFF to FLAC; for small lossy files use AIFF to MP3 or AIFF to M4A.
VLC plays AIFC reliably across Windows, macOS, and Linux. Apple Music/iTunes and QuickTime open AIFC on macOS, including the common codec variants. Windows Media Player is inconsistent with AIFC's codec-specific files. For a guaranteed cross-platform path, MP3 or plain AIFF is safer.
Because AIFC exists to extend AIFF with optional codecs while still defaulting to AIFF's native encoding — big-endian 16-bit PCM. An AIFC file with codec NONE/PCM is equivalent in audio data to an AIFF file; the wrapper is what differs. In our testing, a 60-second 44.1 kHz/16-bit stereo AIFF and its default-codec AIFC output were the same size (~10 MB) and decoded to identical PCM. Choose a lossy codec only when you need the size saving.
Yes, with PCM 24-bit Little Endian selected; the sample rate carries through unless you downsample via the Audio Sample Rate dropdown. Note that very old classic-Mac AIFC tooling sometimes expects big-endian PCM, so a 24-bit little-endian AIFC may not parse in legacy apps — modern DAWs handle both.
Files are uploaded over an encrypted (TLS) connection, processed on our servers, and deleted automatically a few hours after conversion. Nothing is shared or made public, and there's no sign-up or watermark. If you later need the reverse direction, use AIFC to AIFF — lossless when the AIFC held PCM.