AIR File Documentation

Summary

A file with the .air extension is an Adobe AIR Installation Package: a signed, cross-platform installer for an application built with the Adobe AIR runtime. At the byte level it is a ZIP archive (it starts with 50 4B 03 04, “PK”) containing an XML application descriptor, the compiled SWF or HTML app content, its assets, and a code-signing block under META-INF. Its MIME type is application/vnd.adobe.air-application-installer-package+zip. AIR is still maintained — by HARMAN (a Samsung company) since Adobe’s 2020 handover.

Technical details

FeatureValue
Full nameAdobe AIR Application Installer Package
File extension.air
MIME typeapplication/vnd.adobe.air-application-installer-package+zip
Format typeZIP-based signed application installer package
DeveloperAdobe Systems; runtime now maintained by HARMAN (a Samsung company)
Introduced2008 (Adobe AIR 1.0; codename Apollo)
Container / base formatZIP (PKZIP archive)
Byte orderLittle-endian (ZIP structures)
Magic number50 4B 03 04 (“PK\x03\x04”, ZIP local file header) at offset 0
DescriptorXML application descriptor (app id, version, initial content)
SignatureXML digital signature under META-INF (code-signing)
App contentCompiled SWF (ActionScript/Flex) or HTML/JavaScript
Open standardNo (proprietary package layout over ZIP)
Runtime sourceHARMAN AIR SDK & runtime (airsdk.harman.com)
Adobe support EOL31 December 2020 (development continued by HARMAN)
CategoryExecutable Files
Related extensions.swf, .apk, .ipa, .dmg, .exe
File signature (magic bytes)
50 4B 03 04

Offset 0. An .air file is a ZIP archive, so it begins with the ZIP local file header signature 50 4B 03 04 (ASCII “PK” followed by 0x03 0x04), the same bytes that start any ZIP, APK or DOCX. Because it is byte-identical to a plain ZIP, you cannot identify an .air from the magic number alone; it is recognised by its contents — an XML application descriptor plus a code-signing block under META-INF. ZIP structures are little-endian. An empty archive would instead start with the end-of-central-directory signature 50 4B 05 06.

What is an .air file?

An .air file is the packaged, digitally signed installer for an application built with Adobe AIR (Adobe Integrated Runtime), a cross-platform runtime launched in 2008 under the codename Apollo. AIR let developers build desktop and mobile applications using Flash/ActionScript, Flex, or plain HTML and JavaScript, and run them on Windows, macOS, Linux, Android and iOS through the AIR runtime. When you open an .air package with that runtime installed, it installs the application like any other program. Its MIME type is application/vnd.adobe.air-application-installer-package+zip, and the +zip suffix is a literal description of the container: an .air is a ZIP archive.

One fact resolves most confusion about .air files today: AIR is not dead. Adobe ended its own support on 31 December 2020, around the same time as Flash Player, but HARMAN International (a Samsung subsidiary) took over development and continues to ship the runtime and SDK. So the modern way to run an .air installer is to get the runtime from HARMAN, not from Adobe’s now-defunct get.adobe.com/air page. The rest of this article looks at what is actually inside the package.

The ZIP container and why the magic is PK

At the byte level an .air file is an ordinary ZIP archive. It begins with the ZIP local file header signature 50 4B 03 04 — ASCII “PK” (for Phil Katz, PKZIP’s author) followed by 0x03 0x04 — and ends with a central directory and an end-of-central-directory record, exactly like a ZIP, an APK, or a DOCX. This is why an .air cannot be told apart from a plain ZIP by its first bytes alone: the container is generic, and only the contents mark it as an AIR package. All the multi-byte fields in ZIP structures are little-endian.

The practical consequence is that you can rename an .air to .zip, or open it with an archive tool such as 7-Zip, and browse everything inside without installing anything. That inspection is entirely read-only; it does not run or install the application, which still requires the AIR runtime.

The application descriptor

The most important entry in the archive is the application descriptor, an XML file that declares the app’s identity and how the runtime should launch it. It lives in the package (commonly named after the app) and its root element is <application> in an AIR namespace whose URL encodes the SDK version the app targets.

<application xmlns="http://ns.adobe.com/air/application/33.1">
  <id>com.example.myapp</id>
  <versionNumber>1.4.2</versionNumber>
  <filename>MyApp</filename>
  <initialWindow>
    <content>MyApp.swf</content>
    <visible>true</visible>
    <width>1024</width>
    <height>768</height>
  </initialWindow>
</application>

The namespace version (.../air/application/33.1 in the example) tells the runtime the minimum AIR version required and which schema rules apply. The <id> is a reverse-DNS application identifier that must be unique and is used to detect updates and prevent two apps colliding. <versionNumber> drives update logic. <initialWindow><content> names the entry point — the compiled SWF or the root HTML file that the runtime loads first — along with window geometry and visibility. The descriptor can also declare supported platforms, file-type associations, icons and permissions.

The application content: SWF or HTML

An AIR app’s executable content is not native code; it is either a compiled SWF produced from ActionScript/Flex, or an HTML/JavaScript document tree, plus the assets they reference (images, sounds, fonts, embedded libraries). This is the link that causes the common “is AIR the same as Flash?” question: an AIR app is frequently built with the same Flash tooling and its main content can be a SWF, but the two are not interchangeable. A bare SWF is a single piece of playable content; an .air is a full installable application whose runtime grants it desktop capabilities a plug-in SWF never had — local file access, native windows, networking, and OS integration — governed by the descriptor. Extracting the SWF out of an .air gives you the content but not those runtime services, so it will not behave like the installed app.

The META-INF signature block and install integrity

Every valid .air package is digitally signed, and the signature data lives under a META-INF directory inside the ZIP, alongside a mimetype entry that records the AIR installer MIME type. The signature is an XML digital signature (XML-DSig style) that covers the descriptor and the packaged files, binding them to the publisher’s code-signing certificate. When the runtime installs an .air, it validates this signature before installing: it checks that the contents have not been altered since signing and displays the publisher identity and whether the certificate is trusted. This is the same trust model as any signed installer, and it is technically meaningful: an unsigned or tampered package is rejected or flagged, and a self-signed one shows as an unverified publisher.

Because an .air installs and runs software with the permissions the descriptor requests, the relevant precautions are technical: prefer signed packages and read the publisher the runtime shows before confirming; because the package is a ZIP you can extract and inspect the descriptor and content before installing; and obtain the runtime only from the official HARMAN site, since third-party “Adobe AIR” download portals are a known vector for bundled adware. A malicious .air, once installed, can do whatever a normal application can.

AIR packages against native build targets

The .air file is only one of several outputs the AIR SDK can produce from the same project, which is why some “conversions” people ask about are really developer build targets, not file transformations. From one AIR codebase, the SDK can emit a native Windows installer (a “captive runtime” .exe that bundles AIR so the end user needs nothing else installed), an Android APK, or an iOS IPA built with Apple signing. An end user cannot convert an existing .air into an .exe or .apk; only the original developer can repackage from the source. The one genuine transformation available to anyone is renaming to .zip to inspect the contents.

Running an .air after Adobe’s handover

The single most common problem with .air files in practice is not the format but the dead Adobe download link. When Adobe retired AIR at the end of 2020, its runtime download stopped working, so an .air that once double-clicked to install now appears to have no runtime. HARMAN restored and extended the platform: current releases (from version 33 onward, and well beyond) support Windows, macOS, Linux, Android and iOS, including Apple Silicon, and HARMAN even reinstated Linux support that Adobe had dropped after AIR 2.6. Many shipping applications still use AIR — hardware companion tools such as Roland/BOSS Tone Studio, business utilities, and a large catalogue of older games — which is precisely why the runtime remains maintained. Installing the current HARMAN runtime restores the ability to open any .air package.

FAQ

Why does the magic number match a ZIP? Because an .air package is a ZIP archive; the AIR-specific parts (the XML descriptor and the META-INF signature) are files stored inside it. Identify an .air by those contents, not by the 50 4B 03 04 header, which is shared by every ZIP-based format.

Is an .air the same as a SWF or Flash file? Related but not the same. AIR apps are often built with Flash/ActionScript and their main content can be a SWF, but an .air is a complete installable application package with runtime-granted desktop, file and system access, not a single SWF animation.

Can I open an .air without installing it? Yes. Rename it to .zip or open it with 7-Zip to read the application descriptor and browse the assets. To actually run the app you still need the AIR runtime from HARMAN.

References