Initializing... drag & drop files here
Supports: AIFC
They are the same Apple file family, one generation apart. AIFF arrived in 1988, built on Electronic Arts' IFF chunk format, and stores uncompressed big-endian PCM and nothing else. AIFF-C — the .aifc extension — arrived in July 1991 and added a compression-type field, so the identical chunk structure can now hold μ-law, A-law, IMA ADPCM, the classic MACE codecs, floating-point samples, or little-endian PCM under the four-character code "sowt". The short answer: if a tool is rejecting your .aifc, it is almost never rejecting the audio, it is rejecting the compression-type field. Converting to plain AIFF decodes whatever is inside and writes straight 16-bit big-endian PCM that any editor will open.
| Property | AIFC (AIFF-C) | AIFF |
|---|---|---|
| Introduced | July 1991, as an extension of AIFF | 1988, by Apple, based on Electronic Arts' IFF |
| Chunk structure | Identical IFF chunks, plus a compression-type field in COMM | IFF chunks, no compression field |
| Audio payload | NONE (PCM), sowt (little-endian PCM), fl32/fl64 (float), ulaw, alaw, ima4, MAC3, MAC6 | Uncompressed PCM only |
| Byte order | Big-endian, or little-endian when the type is "sowt" | Big-endian |
| Lossy possible? | Yes — μ-law, A-law, IMA ADPCM, and MACE all discard data | No, never |
| File size | Depends entirely on the compression type | About 10.6 MB per minute at 44.1 kHz, 16-bit, stereo |
| Usual extensions | .aifc preferred; .aif and .aiff also used |
.aiff or .aif |
| Tool support | Native on macOS; inconsistent in Windows players and older DAWs | Read by effectively every audio editor, DAW, and player |
| Output written here | — | PCM 16-bit big-endian by default |
.aifc extension is the only unusual thing about it..aifc onto the page or click "+ Add Files" to browse. Queue several files and they run through the same settings in one batch..aiff, individually or as a ZIP for a batch. No sign-up, no watermark.Uncompressed PCM has a fixed data rate — sample rate × bit depth × channels — so you can predict the output size exactly before you convert.
| Output settings | Data rate | One minute | Three minutes |
|---|---|---|---|
| 44.1 kHz, 16-bit, stereo | 1,411 kbit/s | 10.6 MB | 31.8 MB |
| 48 kHz, 16-bit, stereo | 1,536 kbit/s | 11.5 MB | 34.6 MB |
| 44.1 kHz, 16-bit, mono | 706 kbit/s | 5.3 MB | 15.9 MB |
| 8 kHz, 16-bit, mono (voice source) | 128 kbit/s | 1.0 MB | 2.9 MB |
If your AIFC used a compression type, expect the AIFF to be several times larger — that is the compression coming off, not anything being added.
No — nothing can add back detail that a codec already removed. What the conversion changes is the format, not the fidelity. If the AIFC holds plain PCM (compression type NONE, or "sowt" little-endian PCM), the samples pass through unchanged in substance and you simply get a file without the compression-type field that trips up strict tools. If it holds μ-law, A-law, IMA ADPCM, or MACE, decoding to PCM stops any further degradation and gives you a stable editing master, but the detail those codecs discarded is gone for good.
.aifc open on a Mac but not in my Windows DAW?Because most software that reads AIFF was written for the 1988 specification, where the audio is always uncompressed big-endian PCM. AIFF-C added a compression-type code to the COMM chunk, and a reader that does not understand that field will refuse the file even when the payload is ordinary PCM. Apple's own frameworks handle it, so the file looks fine on macOS. Converting to plain AIFF removes the field entirely, which is why the same audio then opens without complaint.
Usually yes, sometimes identically sized. If the AIFC used a real compression type, decoding expands it back to full PCM — a 44.1 kHz 16-bit stereo minute is about 10.6 MB no matter what the source was, so an 8-bit μ-law AIFC roughly doubles and an IMA ADPCM AIFC grows by around four times. If the AIFC was already PCM (NONE or sowt), the AIFF comes out essentially the same size, because both are storing the same raw samples.
The output is 16-bit here. PCM 16-bit big-endian is the default codec for AIFF on this page, and the other choices in the dropdown — 16-bit little-endian, A-law, and mu-law — are also 16-bit or lower. The AIFF specification itself permits higher depths, so if you have a 24-bit master that must stay 24-bit, this conversion is not the right step: keep the original file, or export from the application that created it. For ordinary 16-bit sources, nothing is lost.
"sowt" is "twos" spelled backwards, and it is Apple's pseudo-compression code for little-endian PCM. It sits in the same compression-type field as the real codecs, so a file marked "sowt" is technically AIFF-C even though no compression has been applied — only the byte order differs from a classic AIFF. That is the single most common reason an .aifc behaves like an uncompressed file: it is uncompressed, just byte-swapped and labelled in a way older readers do not expect.
Do not count on it. AIFF and AIFF-C both define chunks beyond the audio — NAME, AUTH, ANNO, and COMT for text, plus MARK and INST for sampler markers, loop points, and instrument data. These are not part of the PCM stream, and a format conversion focuses on the audio. If a recording carries loop points or markers that a sampler depends on, keep the original .aifc alongside the converted file rather than replacing it.
Both are uncompressed PCM containers and hold identical audio quality; the difference is convention. AIFF is big-endian and the Apple-side default, so Logic, GarageBand, and older Mac tooling expect it. WAV is little-endian and the Windows and cross-platform default, and it is the safer choice if the file is going to a mixed team or a Windows-only tool. If your workflow is Mac-based, stay with AIFF; otherwise convert AIFC to WAV. For lossless compression at roughly half the size, AIFC to FLAC is the better archive format.
Your file is uploaded over an encrypted connection, converted on our servers, and deleted automatically a few hours later — no sign-up, no watermark, never shared or made public. Going the other direction is straightforward with AIFF to AIFC, though re-wrapping PCM into an AIFF-C container gains you nothing unless a specific tool asks for that extension. And if the goal was a small, shareable file rather than an editing master, AIFC to MP3 or AIFC to M4A will be an order of magnitude smaller than any PCM output.