Exporting

Once your setup looks right in the preview, exporting turns it into an actual file you can use elsewhere. This page covers the choices in the export sheet and, more importantly, which format to reach for depending on what you're making.

First: what are you exporting?

The export sheet asks you to pick one of three subjects before anything else:

Animation — exports the setup itself as a .blit file (see Library). This isn't a picture or video — it's the recipe. Use this to back up a setup, hand it to someone else with Blitter, or pick it back up later exactly as you left it.
Tile Assets — exports just the single repeating tile and its sequence, on its own (not the whole grid). Use this when you want the raw building block — for example, to drop into a game engine as a texture, or to build your own grid layout somewhere else.
Grid Assets — exports the whole grid exactly as you see it in the preview, time shift, shape mask, gradient and all. Use this when the multi-tile effect is the thing you want — a hero animation, a background, a finished loop to share.

Shared options

Scale — a whole-number multiplier on the tile's pixel size. A tiny procedural tile (say, 10×10px) is easy to work with in the app but usually too small to use directly, so scaling it up (nearest-neighbor, so edges stay crisp) is normal before exporting.
Transparent background — when on, the background is exported as see-through instead of a solid color, so the animation can sit on top of anything. Supported by every format below except MP4 (video doesn't have a transparency channel).

Opaque background	Transparent background

(The checkerboard above is just how design tools indicate "transparent" — your actual export has no checker pattern, that area is simply empty.)

Which format should I actually use?

Format	Best for	Keep in mind
GIF	The universal default — sharing a preview, pasting into a doc or chat, posting anywhere. Works absolutely everywhere.	Frame delays can't go below about 20ms, so very fast/short animations play a little slower than set. Transparency is all-or-nothing per pixel (no soft/partial edges).
PNG sequence	Feeding another tool — a video editor, a compositor, a custom renderer, or anywhere you want to control playback yourself.	Just raw frames, forward order only — no loop/ping-pong/hold timing is baked in, since a folder of PNGs has no concept of timing at all.
APNG	When you need real, smooth transparency (soft gradient edges, partial opacity) and file size isn't the priority — e.g. a hero animation embedded on your own website.	Noticeably larger than GIF for the same content — often 3–4× the size for simple flat-color tiles, since it doesn't compress as aggressively.
MP4	Anywhere video is expected instead of an image — social posts, presentations, embedding with an HTML `<video>` tag (loads faster and smaller than an equivalent GIF).	No transparency support at all. Every frame is stored independently rather than as differences between frames, which keeps pixel edges crisp and the loop point clean, but means a larger file than typical video.
Sprite sheet (Compatible)	Web/CSS-driven playback — a single image you can drive with a CSS `steps()` animation, no extra logic required.	Expands the entire playback cycle (including any hold delays and the ping-pong return pass) into individual frames, so the sheet can be large.
Sprite sheet (Compact)	Game engines or custom players that can implement playback timing themselves. Smaller, since it only stores the base frames plus a small manifest describing mode/delays.	Because it only has the base frames, it can't reproduce a grid's hold delays — tiles that are mid-motion during a hold (due to time-shift) would need those in-between frames, which Compact doesn't include.
ASCII text	Fun, lightweight, code-friendly uses — pasting a tiny animated pattern into a comment, a terminal, or a custom text-based renderer. Tile only.	Not a visual export in the usual sense — it's characters (e.g. `X` for an "on" pixel), so it's only as useful as whatever's going to read that text.

Rule of thumb: if you're not sure, export a GIF first — it's readable everywhere, including right here in this documentation. Reach for APNG or MP4 once you know exactly where the file is going and what that platform needs.

💡 For developers: every sprite sheet export includes a sprite.json manifest with frame positions, playback mode, and delays, plus the full .blit recipe embedded under source — so a sheet can be regenerated later from the same file, without needing the original app session. The ASCII export is a similarly plain-text way to get tile data into code without any image-decoding step at all.

A note on warnings, not blocks

The export sheet will flag things like GIF's frame-delay floor, a sprite sheet crossing a very large pixel size, or a very large grid export — but it won't stop you from proceeding. These are heads-up notices about how the result might look or behave, not hard errors.