Initializing... drag & drop files here
Supports: SWF
Adobe officially ended support for Flash Player on December 31, 2020, and all major browsers blocked Flash content from running on January 12, 2021. That leaves billions of legacy SWF files — e-learning modules, animated banners, vector cartoons, embedded charts — that can no longer be opened by the player they were authored for. Converting key frames to TIFF preserves the visual content in a format that any image viewer, layout tool, or archival pipeline can still read decades from now.
TIFF is the right target when fidelity matters more than file size. With lossless LZW, Deflate, or ZSTD compression, the rendered frame is bit-for-bit identical to the source render — important for design teams, museums, and libraries pulling Flash assets into a long-term archive.
| Property | SWF | TIFF |
|---|---|---|
| Type | Container — vector animation, ActionScript, audio | Raster image (single or multi-page) |
| Year introduced | 1996 (FutureWave FutureSplash, then Macromedia) | 1986 (Aldus, now maintained by Adobe) |
| Compression | Zlib (SWF 6+) or LZMA (SWF 13+) | Uncompressed, LZW, Deflate, JPEG, PackBits, CCITT G4, ZSTD, WebP |
| Color model | RGB / RGBA | Bilevel, grayscale, RGB, CMYK, Lab, palette |
| Animation | Yes (frame-based + ActionScript) | No (multi-page only, no timing) |
| Browser playback | Blocked in all major browsers since Jan 12 2021 | Not natively rendered; opens in image apps |
| Authoring tools today | Adobe Animate (export only), JPEXS, FFDec | Photoshop, GIMP, ImageMagick, every DAM |
| Typical use in 2026 | Legacy archive material | Print masters, scanning, archival |
| Max practical file size | ~2 GB practical (varies by player) | 4 GB classic TIFF, exabyte-scale BigTIFF |
| Compression | Lossless? | Best For | Trade-off |
|---|---|---|---|
| None (uncompressed) | Yes | Forensics, scientific datasets | Largest file size |
| LZW | Yes | General archival, print, Library of Congress recommendation | Universal reader support; modest compression on flat colors |
| Deflate (Zip) | Yes | Smaller lossless files than LZW | Slightly less universal in older RIPs |
| PackBits | Yes | Simple bitmaps with long runs | Weak on photographic content |
| CCITT Group 4 | Yes | 1-bit scanned documents, faxes, legal e-discovery | Bitonal only — no color or grayscale |
| JPEG-in-TIFF | No | Compact previews from photographic SWF frames | Lossy; not suitable for masters |
| ZSTD | Yes | Modern archival, best ratio | Newer; not universally supported in legacy tools |
| WebP-in-TIFF | Both modes | Compact storage when target reader is modern | Limited tooling outside libtiff 4.1+ |
Because the bits aren't dead — only the player is. SWF files still contain the original frames, vector shapes, and bitmaps; you just need a renderer that isn't the discontinued Flash Player. xconvert renders each requested frame server-side using a Flash-compatible engine, then encodes the result as TIFF. The output is a normal image file that will outlive any browser plugin policy.
By default xconvert captures the first frame of the SWF timeline. For most banner ads and title cards that frame is meaningful, but for long timelines (e-learning, cartoons) you almost certainly want Multiple Screenshots with a 1, 2, or 5 second interval, or Specific Frame with a timestamp from the source material.
Yes — use Multiple Screenshots with the smallest frame interval and the converter will write one TIFF per captured frame, packaged together. For a 30 FPS SWF set the interval at 1 frame to get a 1:1 dump of the timeline. Be aware that complex SWFs (ActionScript-driven, randomized) won't always render deterministically across runs.
For preservation, LZW is the safest default: lossless, near-universal reader support since the early 1990s, and explicitly listed as a preferred TIFF compression in the Library of Congress's recommended formats statement. Pick Deflate if you need slightly smaller files and your downstream tools are modern. Pick JPEG-in-TIFF only when the source frame is photographic and the file will be used as a preview, not a master — JPEG is lossy and degrades on re-saves.
For screen reuse, 72 or 96 DPI matches the SWF's authored resolution. For print, set 300 DPI and bump the pixel dimensions accordingly — remember that SWF is vector-source, but xconvert rasterizes at the resolution you specify, so a small SWF stage will look blocky if you ask for a giant TIFF. Multiply the SWF's authored stage size by the DPI ratio you need.
Partially. Static and simple timeline-based animations render cleanly. ActionScript 1/2 frames usually render. ActionScript 3 content that relies on runtime data, external XML, or user input may render an incomplete first frame. For complex AS3 SWFs, JPEXS Free Flash Decompiler is a useful companion tool — open the SWF, navigate to the frame you want, then export and feed the result back here for TIFF re-encoding.
Both are lossless raster formats. TIFF wins for institutional archives because it supports CMYK, true bitonal, 16-bit-per-channel depth, multi-page layout, and named compression schemes that scanning vendors and DAM systems already understand. PNG wins for the web — it's smaller for simple graphics and every browser renders it. If your downstream tool is print or a library catalog, choose TIFF; if it's a website, see SWF to PNG instead.
Then TIFF isn't the right target. To keep the animation, convert to SWF to MP4 for video, SWF to GIF for short looping animations, or SWF to JPG if you just need a quick web preview frame. TIFF carries no timing information, so any animation is lost the moment you encode to it.