SWF files: how browser engines process classic Flash content

SWF files do not run in modern browsers because browsers still “support Flash.” They run only when a compatibility layer, typically a WebAssembly-based emulator such as Ruffle, takes responsibility for parsing the file and executing its bytecode in a controlled environment. That distinction is the entire bottleneck.

Adobe ended Flash Player support on December 31, 2020, and the plugin kill-switch began blocking Flash content on January 12, 2021. Since then, opening an old .swf file has no connection to the old browser-plugin workflow. The file itself may still contain the complete game, animation, interface, or interactive advertisement, but the execution environment that once understood it is gone.

To understand how classic Flash content works today, we need to follow the actual pipeline: binary header, compressed payload, tag stream, vector and bitmap assets, ActionScript virtual machine, then the emulator layer that maps all of this onto a modern browser.

The binary anatomy: what an SWF file contains before execution

An SWF file is a compiled binary stream, not a document format like XML or JSON. That matters because you cannot inspect it meaningfully by opening it in a text editor. The file contains packed data structures, asset definitions, display commands, frame information, and ActionScript bytecode arranged according to the SWF format.

The first useful checkpoint is the file header. An SWF begins with an 8-byte header, and its first three bytes identify the compression state:

The signatures were introduced at different points in the format’s evolution. CWS compression appeared with SWF 6, while ZWS was introduced with SWF 13. The signature is therefore more than a file-extension detail: it tells the loader which decoding path to use before it can reach the actual content.

The header also carries information needed to interpret the rest of the file. The exact layout is binary and bit-packed, so the parser cannot simply move through the file by looking for readable strings. It has to read fields at the correct bit offsets, interpret their widths, and then advance to the next structure.

That is one reason emulation is not a trivial matter of replacing a missing browser plugin. A modern Flash emulator needs to reproduce a format parser, a display-list system, a bytecode runtime, timing behavior, input handling, and rendering logic. If one layer is slightly wrong, a game may load but still fail on menus, animation, sound, save states, or input events.

Compression changes the first stage, not the file’s logical architecture

Whether the file is marked FWS, CWS, or ZWS, the logical content remains organized around the same broad idea: define assets, place them into a display structure, advance frames, and execute actions.

Compression only changes how the binary payload is stored. A compressed SWF is not a different kind of game or animation. It is the same general format packaged for smaller transfer and storage. The browser-side compatibility layer must decompress it first, then process the resulting tag stream.

This is a useful distinction when diagnosing old Flash games. If a file fails immediately, the problem may be signature recognition or decompression. If it loads to a title screen but breaks when you start playing, the likely failure is further down the stack: unsupported ActionScript behavior, display-list differences, timing, or an incomplete API implementation.

The .swf extension tells you what the file is called. The header tells the emulator how to begin understanding it.

Tag-based architecture: definitions, display commands, and frames

After the header and compression stage, the parser reaches the tag stream. This is the working core of the SWF file.

The stream is divided into tags that describe assets and tags that control how those assets appear or behave. The cleanest way to think about the architecture is as a dictionary plus a timeline.

Definition tags create reusable objects and store them in the file’s internal dictionary. These objects can include vector shapes, bitmap images, fonts, sounds, text fields, and other resources. Examples include DefineShape for vector geometry and DefineBitsJPEG for JPEG-based image data.

Display and control tags then use those definitions. A tag such as PlaceObject puts an asset on the display list. RemoveObject takes it off. ShowFrame advances the timeline, and DoAction triggers ActionScript instructions associated with that point in execution.

The same asset can be defined once and placed many times. A game does not need to store a separate copy of every identical enemy, button, or tile. It can keep one definition in the dictionary, then create multiple placements with different positions, scales, transformations, or visual states.

That is a strong design for the type of content Flash was built to deliver:

• Vector assets remain compact and can be transformed without storing a new raster image for every size.
• Reusable objects reduce duplication in game scenes and animations.
• Timeline control separates asset storage from the question of when an asset appears.
• ActionScript can change placements, react to input, and trigger transitions during execution.

The display list is not the same thing as a modern HTML page

It is tempting to translate the Flash model directly into DOM terms, but that creates bad assumptions. An SWF is not a tree of HTML elements waiting for CSS layout. Its visual state is driven by a display list and timeline instructions.

A parser first learns what objects exist. The runtime then determines which objects are currently placed, their depth and transforms, which frame is active, and what actions should execute. The renderer turns that state into pixels or drawing operations inside the browser’s compatibility layer.

This explains why an old game can have all its assets present and still appear broken. Loading a bitmap or shape definition does not mean the game’s active display state is correct. A missing PlaceObject operation, a failed ActionScript call, or a difference in frame control can leave the screen blank even though the underlying resources are intact.

The same issue appears in interfaces. A button may be defined correctly but never receive the event behavior that makes it clickable. A level may be placed on the timeline but fail to advance because the associated action did not execute. Preservation is therefore about behavior, not merely extracting pictures and sounds from an archive.

Why tag order matters

The tag stream is sequential, and execution depends on that sequence. Definitions generally need to be available before the runtime can use them. Control tags then modify the current display state as the file advances.

A simplified execution pass looks like this:

1. Read the header and determine the compression method.

2. Decompress the payload when required.

3. Parse the tag records in order.

4. Add asset definitions to the internal dictionary.

5. Apply display-list operations.

6. Process frame boundaries.

7. Execute ActionScript actions associated with the current state.

8. Render the updated frame and wait for the next timing step.

That sequence is not a user-facing checklist so much as the reason a browser emulator must be stateful. It cannot treat the SWF as a collection of independent images. It has to preserve the relationships between definitions, placements, actions, and frames.

Coordinate systems and bit-packing: why Flash geometry is unusually precise

Flash’s visual system was designed around vector graphics, and its coordinate model is not based solely on ordinary pixels. SWF geometry uses a unit called the twip.

One twip equals one-twentieth of a pixel, or 1/1440 of an inch. This gives the format a much finer coordinate grid than a pixel-only system. Shapes, transformations, and positions can be represented with subpixel precision, which is useful when scaling vector art or animating objects smoothly.

The practical consequence is that the emulator cannot casually round every coordinate to the nearest screen pixel. It needs to preserve the internal values and apply the appropriate transformation when rendering to the browser’s current viewport.

This matters especially in games with:

• Small collision boundaries.
• Precisely aligned tile maps.
• Scaled vector interfaces.
• Rotating or zooming objects.
• Camera movement that exposes subpixel positioning.
• Animations that rely on consistent interpolation between frames.

A one-twip difference may be visually irrelevant in a static icon. It can be more noticeable in a rapidly moving sprite, a narrow platform, or a cursor-sensitive menu. The browser output is pixel-based in the end, but the SWF logic may operate at a more precise internal scale before rasterization.

Bit-packed structures save space but increase parser complexity

SWF files also use bit-packed data structures. Instead of giving every value a generous fixed-width field, the format can store values using only the number of bits needed by a particular record.

That was an efficient decision for a format designed to move interactive media over the web. It is less friendly to modern debugging. A parser must track bit positions carefully, distinguish signed and unsigned values, and understand how variable-length fields affect the next record.

The geometry of a shape is therefore not just a list of plain coordinates. It may include compact records describing edges, fills, line styles, and state changes. The parser reconstructs those records into a usable representation before the renderer can draw the shape.

This is one of the places where “just convert Flash to HTML5” becomes an oversimplification. A conversion tool may successfully extract assets or translate a limited subset of behavior, but faithful execution requires the format’s packed data and runtime semantics to be understood together.

Vector assets are not automatically easier to emulate

Vector graphics often get treated as the simple part because they scale better than bitmaps. The file may indeed store a shape compactly, but rendering it correctly still involves fill rules, line styles, transforms, clipping, and display-list state.

An emulator has to reproduce enough of the original visual behavior that the content remains playable rather than merely recognizable. A character that looks approximately correct in a screenshot is not sufficient if its hitbox, layering, or animation state is wrong.

That is the preservation standard worth using: not whether the asset can be displayed, but whether the interactive result survives.

ActionScript execution: AVM1 versus AVM2

The visual layer only gets the game to the starting line. Interactivity comes from ActionScript bytecode and the virtual machine that executes it.

Flash content uses two major execution environments:

• AVM1 runs ActionScript 1 and ActionScript 2.
• AVM2 runs ActionScript 3 and was introduced with Flash Player 9.

This split is strategically important when assessing compatibility. Older web games often rely on AVM1 behavior, while later projects may use AVM2 and ActionScript 3. The two virtual machines are not interchangeable implementations with different labels. They represent different runtime generations, bytecode expectations, and execution models.

A file can therefore fail in several distinct ways:

1. The SWF parser cannot read the file structure.

2. The assets load, but the required virtual machine is incomplete.

3. ActionScript executes partially but calls an unsupported API.

4. The script runs, but timing or event behavior differs.

5. The runtime reaches a state the emulator does not yet reproduce accurately.

The visible symptom may be identical: a black screen, frozen menu, missing character, or unresponsive button. The underlying cause is not.

Bytecode is executable logic, not the original source project

ActionScript inside an SWF is compiled bytecode. It is not the original .fla project and it is not a readable source-code archive. A decompiler may recover approximations of classes, functions, or names, but that process is separate from normal browser execution and does not restore the original development project automatically.

For a browser emulator, the objective is different. It does not need to reconstruct the developer’s source files. It needs to execute the compiled instructions well enough to reproduce the content’s behavior.

That includes ordinary game logic:

• Reading keyboard or mouse input.
• Updating object positions.
• Checking collisions.
• Changing animation frames.
• Loading or switching scenes.
• Updating scores and interface text.
• Triggering sound or visual effects.
• Managing timers and event callbacks.

The game’s apparent simplicity does not reduce the runtime burden. A small arcade title can be more sensitive to event ordering or frame timing than a static animation because the player’s input is part of the state.

A preserved SWF is not preserved merely when its first frame opens. It is preserved when the runtime can still execute the decisions that make the game a game.

AVM compatibility is a major optimization target

If we are trying to get a classic Flash title running efficiently, the first question is not whether the file has attractive graphics. It is which runtime path it depends on.

An AVM1-heavy game may be a better candidate for broad emulator compatibility than an AVM2 project with deeper dependencies, but there is no universal rule. The file’s ActionScript version, API usage, external asset behavior, and timing assumptions all matter.

The useful triage order is:

• Identify the SWF version and compression signature.
• Determine whether the content relies primarily on AVM1 or AVM2.
• Check whether the game uses external files or expects a particular host environment.
• Observe whether failure occurs during loading, input, scene transition, or ongoing simulation.
• Separate rendering errors from runtime errors before changing the file itself.

That approach saves time because it avoids treating every broken Flash game as a generic “browser compatibility” problem.

The post-plugin era: how WebAssembly emulators bridge the gap

Modern browsers do not natively parse and render SWF files as part of their regular web platform. The missing Flash Player functionality is supplied by external compatibility layers, commonly open-source emulators such as Ruffle.

Ruffle is written in Rust and compiled into WebAssembly. The browser loads the WebAssembly module, and that module performs the work that the old plugin once handled: parsing SWF structures, running compatible ActionScript behavior, maintaining display state, and sending output through browser-supported rendering paths.

The broad architecture looks like this:

This is a compatibility stack, not native Flash support. The browser is hosting the emulator; it is not suddenly gaining the original plugin architecture back.

Why WebAssembly is the practical bridge

WebAssembly gives emulator developers a portable execution target with predictable integration into modern browsers. The emulator can be distributed as web-compatible code rather than asking users to install a discontinued plugin with privileged browser access.

The security model also changes. The old plugin approach depended on browser plugin interfaces that modern browsers removed for good reasons. A WebAssembly emulator runs under the browser’s current sandboxing model and uses browser APIs through controlled interfaces.

That does not guarantee perfect compatibility. It does make the deployment model viable. We can load a classic SWF from a modern page without reviving NPAPI or PPAPI plugins, provided the emulator supports the file’s format and behavior.

Ruffle is an interpreter and compatibility project, not a magic conversion button

The emulator still has to implement the relevant pieces of the Flash ecosystem. Some games will work immediately. Others may show partial rendering, fail at a specific screen, or require additional compatibility work.

The difficult cases are usually not solved by changing the file extension or compressing it differently. The problem is often semantic:

• A particular ActionScript instruction behaves differently.
• An old API is missing or only partially supported.
• Mouse or keyboard events arrive in a different form.
• Frame timing changes the result of game logic.
• A content-loading assumption no longer applies.
• The SWF depended on browser or server behavior that disappeared with the original site.

This is why the most useful test is not “does the loading screen appear?” The useful test is whether the complete gameplay loop works: input, state updates, transitions, scoring, audio, and restart behavior.

Browser execution introduces a different timing environment

Flash content was originally authored for a plugin runtime with its own frame and event behavior. A WebAssembly emulator has to map that behavior onto the browser’s event loop and rendering schedule.

The exact frame-rate limits and timing discrepancies across non-standard SWF implementations are not universal, so it is better not to pretend that every title will behave identically. What we can say is that timing is part of compatibility. A game may render correctly while its simulation runs too quickly, too slowly, or inconsistently under a different execution environment.

For action games, that can alter difficulty and input windows. For strategy and puzzle titles, it may appear as delayed clicks, broken timers, or animations that do not advance when expected. In resource-heavy games, timing differences can also change the optimal rotation: a cooldown, spawn cycle, or scripted event may no longer align with the original cadence.

The correct response is diagnosis rather than blind optimization. Reduce the problem to a repeatable interaction, identify where the state diverges, and then determine whether the issue belongs to parsing, ActionScript, events, or rendering.

From SWF file to browser frame: the complete execution path

It helps to treat the process as a sequence of transformations rather than one act of “playing Flash.”

1. The browser loads the compatibility layer

The page starts the WebAssembly emulator. The browser supplies the modern runtime environment, but the emulator supplies the Flash-specific logic.

2. The emulator reads the SWF header

The three-byte signature identifies whether the payload is uncompressed, zlib-compressed, or LZMA-compressed. The rest of the header provides the structural information required to interpret the file.

3. The payload is decompressed when necessary

For CWS and ZWS files, the emulator expands the compressed data before parsing the tag stream. An FWS file skips this stage.

4. Tags build the internal content model

Definition tags populate the dictionary with shapes, images, text, sounds, and other resources. Control tags establish the current display state and frame progression.

5. The ActionScript runtime begins executing

The emulator selects the relevant virtual machine behavior for AVM1 or AVM2 and runs the compiled bytecode. The script can alter the display list, respond to input, update variables, and trigger new actions.

6. The renderer produces the visible output

Vector shapes are rasterized, bitmaps are placed, text and interface objects are drawn, and the current display state is presented through browser-compatible graphics APIs.

7. Browser events feed the next simulation step

Keyboard, mouse, focus, audio, and timing events move back into the emulated runtime. The cycle repeats as the game advances from frame to frame.

This pipeline explains why preservation projects often need more than the SWF alone. The file may reference external assets, expect a specific host page, or assume runtime APIs that are no longer available. A standalone file can be technically intact while the complete game environment is incomplete.

Common failure modes when running classic Flash content

The fastest troubleshooting method is to classify the failure by where it appears in the pipeline.

The file does not load at all

Start with the header and compression path. A malformed file, unsupported compression method, or incomplete transfer can stop execution before any visual content appears.

Do not begin by editing ActionScript if the parser never reaches the tag stream. That is the digital equivalent of tuning the engine before checking whether the car has fuel.

The file loads, but the screen is blank

A blank screen can indicate failed display-list operations, unsupported ActionScript initialization, incorrect frame handling, or an asset that never gets placed. The presence of a valid SWF header does not prove that the first visible state was built successfully.

Look for the last successful stage rather than guessing. If the background appears but the interface does not, the parser and renderer may be working while the script-driven elements fail. If nothing appears, the problem may be earlier.

The menu appears, but buttons do nothing

This usually points toward input events, ActionScript behavior, or focus handling. The button graphic may be defined and rendered correctly while its event listener or hit detection logic fails.

The distinction matters because replacing the asset will not repair the runtime. We need to determine whether the click reaches the emulator, whether the hit area is defined, and whether the associated action executes.

Gameplay starts, then breaks during a transition

Scene changes are useful stress tests because they exercise more of the file: frame navigation, new asset placements, cleanup of old objects, script calls, and sometimes external loading.

A game that survives the title screen but fails when starting a level is not “mostly working” in any meaningful preservation sense. The critical path is the playable loop, not the splash screen.

Visual output is present, but gameplay speed is wrong

Treat this as a timing problem until proven otherwise. The renderer may be accurate while the emulated frame progression or event scheduling differs from the original environment.

Avoid compensating casually by changing game variables. That can hide the symptom while producing a version that no longer matches the original behavior. For preservation, the target is faithful execution; for casual play, a timing workaround may be acceptable, but it should be recognized as a compromise.

The practical hierarchy for Flash preservation and emulation

Not every technical detail deserves equal attention when deciding whether a classic web game is likely to run. If the goal is to save time, prioritize the layers with the highest failure impact.

1. File integrity comes first.

A missing byte or damaged compressed stream prevents every later stage from functioning. Confirm that the SWF is complete before investigating runtime behavior.

2. Compression and version determine parser compatibility.

FWS, CWS, and ZWS require different decompression handling. The SWF version also helps identify the expected feature set.

3. ActionScript generation is the main runtime gate.

AVM1 and AVM2 content may have very different compatibility profiles. A visually simple game can still be difficult if its scripting dependencies are not supported.

4. Display-list behavior determines whether loaded assets become a game.

Shapes and images sitting in the asset dictionary are irrelevant unless placement, depth, transforms, and frame control are correct.

5. Input and timing decide whether the result is playable.

A title screen is not proof of success. Test interaction, level transitions, scoring, restart, and the complete gameplay cycle.

6. External dependencies can outweigh the SWF itself.

Old web games sometimes relied on a host page, server calls, additional media, or browser behavior that is no longer present. Preservation work must account for that surrounding context.

The optimal emulation strategy is not to chase every visible glitch first. Fix the earliest broken layer in the execution pipeline, because every later symptom may be collateral damage.

Why SWF still matters to browser game preservation

SWF is often discussed as obsolete technology, and as a deployment platform it is. But obsolete does not mean irrelevant. A large portion of classic web gaming history was authored for Flash, from short arcade experiments to educational projects and full browser-based strategy games.

Those works are not reducible to screenshots. Their value is in the interaction model: input timing, animation rules, score systems, progression, sound cues, and the small mechanical decisions that made one title feel different from another.

That is also why emulation is preferable to asset extraction when the goal is historical fidelity. Exporting sprites and music may preserve ingredients, but not the recipe. Rebuilding a game in another engine can produce a playable remake, yet it may introduce different collision behavior, timing, rendering, or input response. An emulator attempts to preserve the original execution model instead.

The tradeoff is obvious. Emulation inherits the quirks and limitations of the old platform, and modern compatibility layers cannot promise perfect support for every SWF. But that is a more honest preservation target than pretending the original format can be converted into clean modern code with one automated click.

TL;DR: prioritize the execution stack, not the file extension

The swf file structure and browser execution process begins with an 8-byte header and one of three signatures: FWS, CWS, or ZWS. After decompression, the browser-side emulator parses the tag stream, separates reusable asset definitions from display and control commands, reconstructs the timeline, and executes ActionScript through AVM1 or AVM2-compatible runtime logic.

Modern browsers do not natively run SWF files. WebAssembly emulators such as Ruffle bridge the gap by recreating the relevant Flash behavior inside the browser’s current sandboxed environment.

For the best troubleshooting ROI, use this priority order:

1. Verify the SWF is intact.

2. Identify its compression and version.

3. Determine whether it depends on AVM1 or AVM2.

4. Check display-list and frame progression.

5. Test input, timing, transitions, and restart behavior.

6. Investigate external dependencies only after the core file and runtime path are understood.

The extension is the easy part. The real preservation challenge is keeping the binary format, virtual machine, display system, and browser execution environment aligned closely enough that the old game still behaves like a game.