JPEXS Free Flash Decompiler: twenty years of turning SWF binaries back into ActionScript

What the tool does with an SWF file

The README describes the project in one line: an open source Flash SWF decompiler and editor that extracts resources, converts SWF to FLA, edits ActionScript, and replaces images, sounds, texts and fonts, with several output formats available and Java support on Windows, Linux and macOS.

The list of capabilities is the argument for using it. Extracting resources means you can get the individual assets out of a compiled binary. Converting SWF to FLA hands the timeline to Adobe Flash Professional's native format, which matters for anyone with a copy of that application. Editing ActionScript is the reverse direction: read the decompiled source, change it, and put it back. Replacing images, sounds, texts and fonts covers the localisation and re-skinning work that made Flash content expensive to maintain in the first place.

The scale is substantial for a desktop utility. The project has 5,883 stars and 787 forks, with only 2 open issues, and it is written in Java. The default branch is `master`, the last push was 2026-09-20, and the most recent stable release is version 26.3.0 from 2026-09-14, with a nightly prerelease cut the same day as the last push.

It is worth naming the obvious caveat up front. Flash is a discontinued technology, its plugin is gone from every modern browser, and the FLA export target depends on software Adobe no longer sells. What has not gone away is the enormous quantity of Flash content sitting in archives, on old disks and inside games that people still want to read, translate or study. That is the corpus this tool serves.

Getting the source, and why there are two branches

The source is fetched with an ordinary clone:

git clone https://github.com/jindrapetrik/jpexs-decompiler.git

The branch structure is the part to understand before you build. `master` holds released stable versions. `dev` holds the newest work from developers and is what the nightly builds are cut from. Moving between them is a normal checkout:

git checkout dev

That arrangement is worth a note, because it tells you what kind of project this is. The `dev` branch is treated as always-buildable, and a release is a merge rather than a hand-prepared event. It also means that anyone reading source for reference should probably use `master`, because `dev` carries changes that have not had a stable tag.

The README recommends having git command line executables installed, with a specific reason: the build script calls git to embed the revision number into the binary, and on Windows you have to enable Git in the command line during installation. That is the kind of detail that would otherwise surface as a build failure with no obvious cause.

Version numbers follow the format `x.y.z`, for example `9.1.2`, and the project states it tries to use semantic versioning. Nightly builds append a `_nightlyN` suffix where N increments on every automatic nightly release and, as the README points out specifically, is not reset when a stable version is released. Nightly versions are not available through git tags.

Nine libraries that have to be built too

This is where a project of this age shows its age, in a way that is instructive rather than merely inconvenient. The source tree contains a `libsrc` directory with libraries that must be compiled separately, and the README enumerates them.

`FFDec_lib` is the core: decompilation, SWF parsing and export. It builds automatically with the main project and has its own Ant script if you want it separately. `jpacker` handles compression of JavaScript Canvas scripts and is a Netbeans or Ant project. `jpproxy` is the proxy part of FFDec. `jsyntaxpane` is the code editor component, a Netbeans and Apache Maven project. `LZMA` is used for SWF compression, `nellymoser` for decoding Nelly Moser sounds, `Swf2Exe` as a stub for the save-to-EXE feature as a Delphi 7 project, `ttf` for TrueType font export, and `gnujpdf` for PDF export.

Two different build systems are in play. The main source contains a Netbeans project, so you can open it in Netbeans and use the standard Run, Build, Debug and Clean actions, with project-specific tasks exposed through the `build.xml` menu. If you do not want Netbeans, Apache Ant works: install Ant, put it on your PATH, navigate to the source directory, and run `ant run` to launch the application or `ant build` to compile only.

The repository tree confirms the shape of this: alongside `src/`, `lib/` and `libsrc/` there are `nbproject/` and `nbbuild.xml` for Netbeans, `build.xml`, `build.properties`, `buildconfig.xml` and `antlib/` for Ant, `checkstyle.xml` and an `ffdec-findbugs-config.fbp` for static analysis, and `cicd_scripts/` for automation. Packaging infrastructure is also present in the form of `installer.iss` for Inno Setup, `installer.nsi` with `nsis_locales/` for NSIS, and a `wix/` directory, so Windows installers are built from more than one toolchain.

Docker for headless runs, and a CLI entry point

There is a `Dockerfile` in the repository for running the command line interface without installing Java or the application locally. The README credits the original script to Mahdi Lazraq, which is a nice touch of attribution for a container definition.

The base is an Eclipse Temurin 21 JRE image, which is the correct choice for a Java application that only needs to run. Unzip and xvfb are installed along with the X11 libraries the Swing interface needs, and the release ZIP for version 26.3.0 is downloaded and unpacked into `/opt/ffdec` at build time rather than installed from a package manager.

The build and usage are two short commands:

docker build -t ffdec .

docker run --rm -v ./input:/work/input -v ./output:/work/output ffdec [args]

Two details in the container setup are the interesting part. Pinning the exact version tag in the Dockerfile means a rebuild gets the release you intended rather than whatever is latest, which matters for a tool whose output feeds into a pipeline. And running it with a virtual framebuffer is what makes headless operation possible at all, since the application is a desktop program even when invoked as a CLI.

The README notes that FFDec CLI is the entry point, so arguments pass straight through. That makes the container usable in scripts: mount a directory of SWF files in, mount somewhere to write, and pass the same flags you would use locally.

One author, a long contributor list, and releases cut by CI

The authorship section is unusually specific. The decompiler was originally written by Jindra Petřík, also known as JPEXS, and the application was made in the Czech Republic. He is listed as leader, responsible for decompiler development, website administration and account administration.

The developer list adds honfika for decompiler development and Paolo Cancedda as a former developer, followed by other contributors on GitHub and Google Code. Then there is a translators list covering nineteen languages, from Catalan and Swedish through Chinese, Russian, Hungarian, Italian, German, French, Portuguese, Polish, Turkish, Ukrainian, Spanish, Brazilian Portuguese, Japanese, Dutch, Slovenian, German and Slovak. The German and Slovak entries credit GitHub Copilot with Claude AI, which is a recent addition to a list that otherwise names individuals.

The release process is fully automated, and the README describes both halves. When a commit lands on `dev`, GitHub Actions creates a new prerelease and removes the previous nightly, so only one nightly exists at a time. When `dev` is merged into `master`, CI creates a stable version and adds a tag in the format `versionx.y.z`. A stable release ships an MSI installer for Windows, a ZIP for Windows, Linux and macOS, a Debian package, and a macOS build, as the release entries show.

Documentation lives in the wiki rather than the repository. The README points there for application description and features and for installation, and points to the FAQ and known problems pages before you file anything. The issue tracker has not moved: it remains on the free-decompiler.com site, a leftover from the pre-2018 arrangement when that domain was the homepage. Contact by email is available but explicitly discouraged in favour of the tracker.

The application is licensed GPL v3, or GPL-3.0-or-later as the README phrases it, with the text in `license.txt`. The README notes that the application uses modified code of other projects, and the repository carries `TRANSLATIONS.md`, `SECURITY.md`, `CONTRIBUTING.md` and a `CHANGELOG.md` alongside `LICENSE`, so the governance files are all present in the tree.

Editorial conclusion

This is a mature project rather than a nostalgia exercise, and the evidence is in the maintenance details more than the star count. Releases ship as an MSI installer, a cross-platform ZIP, a Debian package and a macOS build, nightly prereleases are cut automatically from a `dev` branch, and the Dockerfile pins a specific version tag so a container rebuild lands on a known release rather than latest. The GPL-3.0-or-later licence on the application is the term most worth understanding before use, because extracting and editing other people's Flash content is legally sensitive and the licence covers the tool, not the artwork. Practically, you download the release, and the wiki handles installation and the feature list, so the README is a build and architecture document. That is the right division of labour for a project whose documentation lives in a wiki and whose audience includes people recovering assets from files that no browser will open any more.

Frequently asked questions

Official sources

1. Issues
2. jindrapetrik/jpexs-decompiler on GitHub
3. License: GPL-3.0
4. README
5. Releases