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 Gallery). 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.
Block Assets — exports just the single repeating block 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-block 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 block's pixel size. A tiny procedural block (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 H.264 video (that codec has no transparency channel). HEVC video can keep the transparency, and that file is always a MOV.

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 blocks, since it doesn't compress as aggressively.
Video	Anywhere a movie file is expected instead of an image — social posts, presentations, embedding with an HTML `<video>` tag (loads faster and smaller than an equivalent GIF). Pick MP4 for the web and chat apps, or MOV for QuickTime and editors. H.264 is the compatible default; HEVC makes a smaller file.	H.264 always includes the background. HEVC is the codec that can keep a transparent background (HEVC-with-alpha) — that file is always MOV, because an MP4 can't carry it. It plays in QuickTime, Safari, and Final Cut; Chrome and Windows may ignore the alpha or refuse the file. Every frame is stored independently rather than as differences between frames, which keeps pixel edges crisp and the loop point clean. Video has no loop flag — enable looping in the player.
Sprite	Game engines, CSS, or a webpage that should play the sheet itself. Block Assets offer Compatible (whole cycle in the frames, CSS `steps()`) or Compact (fewer frames, timing in `sprite.json`). Grid Assets write a Compact block atlas of coverage masks plus per-cell time-shift in the manifest; `embed.html` blits those onto a canvas so delays and gradients match the preview. Turn on Flatten grid if you need one rectangle of pre-composited frames instead.	Flattened Compatible sheets can be large. The optional snippet writes `embed.html` next to `sprite.png`.
ASCII text	Fun, lightweight, code-friendly uses — pasting a tiny animated pattern into a comment, a terminal, or a custom text-based renderer. Block 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 Video once you know exactly where the file is going and what that platform needs.

💡 For developers: every sprite 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. A grid sprite (unless flattened) also carries grid.offsets and grid.mask so a player can instance the block atlas with time-shift, without reimplementing Blitter's field math. Turn on HTML/CSS snippet to also get embed.html, a drop-in page that plays sprite.png. The ASCII export is a similarly plain-text way to get block 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.