About

ASCII art animation predates modern graphics by decades. Artists create frame-by-frame motion using characters from the 95-printable subset of US-ASCII (codes 32 - 126). Converting these text frames into a distributable GIF requires binary-level encoding: a GIF89a header, a Global Color Table mapping N colors to 3-byte RGB triplets, Graphics Control Extensions specifying per-frame delay in centiseconds, and LZW-compressed pixel data for each Image Descriptor block. Errors in the LZW code table or missing trailer bytes produce corrupt files that silently fail in browsers. This tool performs real GIF89a encoding entirely in your browser with no server round-trip.

The encoder maps each character cell to a pixel block of configurable size, applies your chosen foreground and background colors, and compresses frames using variable-length LZW with a minimum code size of 2 bits. Frame delay d is specified in hundredths of a second (centiseconds), so a value of 20 yields 50 fps apparent playback. Note: most renderers clamp minimum delay to 20 ms regardless of specification. The tool approximates smooth animation within these browser-imposed constraints.

Formulas

Each ASCII frame is rendered onto a canvas where every character occupies a cell of w × h pixels determined by the monospace font metrics. The total image dimensions are computed as:

W = cols × w H = rows × h

where cols is the maximum line length across all frames and rows is the maximum line count. Frame delay in the GIF spec uses centiseconds:

d_cs = 100fps

LZW compression begins with a code table of size 2^minCodeSize + 2 (including Clear and EOI codes). The compressor emits variable-length codes starting at minCodeSize + 1 bits, increasing width when the table index reaches 2^currentBits. The table resets via a Clear Code when it reaches 4096 entries (the 12-bit maximum).

codeWidth = ceil(log₂(tableSize + 1))

where W = image width in pixels, H = image height in pixels, cols = character columns, rows = character rows, w = cell width in pixels, h = cell height in pixels, d_cs = frame delay in centiseconds, fps = frames per second, minCodeSize = LZW minimum code size (typically 2 for small palettes), codeWidth = current LZW output bit width.

Reference Data

GIF Block	Offset	Size (bytes)	Purpose
Header	0	6	Signature + Version (GIF89a)
Logical Screen Descriptor	6	7	Canvas width, height, color table flags
Global Color Table	13	3 × 2^N	RGB palette entries
Application Extension	Variable	19	NETSCAPE2.0 looping block
Graphics Control Ext.	Per frame	8	Delay time, disposal method, transparency
Image Descriptor	Per frame	10	Frame position, dimensions, local table flag
Image Data	Per frame	Variable	LZW min code size + sub-blocks
Trailer	Last	1	Byte 0x3B signals end of file
LZW Min Code Size	-	1	Typically 2 - 8 bits
LZW Clear Code	-	-	2^minCodeSize
LZW EOI Code	-	-	Clear Code + 1
Max Code Size	-	-	12 bits (4096 entries max)
Sub-block Max	-	255	Max bytes per data sub-block
Disposal Method 0	-	-	No disposal specified
Disposal Method 1	-	-	Do not dispose (overlay)
Disposal Method 2	-	-	Restore to background color
Disposal Method 3	-	-	Restore to previous frame
Common Delay: 10 fps	-	-	10 centiseconds per frame
Common Delay: 5 fps	-	-	20 centiseconds per frame
Common Delay: 2 fps	-	-	50 centiseconds per frame
Max GIF Dimensions	-	-	65535 × 65535 px

Frequently Asked Questions

The GIF specification stores delay in centiseconds (hundredths of a second). Most browsers and image viewers clamp the minimum delay to approximately 20 ms (effectively capping at ~50 fps). If you set a delay below 20 ms, renderers may substitute a default of 100 ms instead, making the animation appear much slower. For reliable playback, use delays of 4 centiseconds or greater.

ASCII art GIFs tend to compress very efficiently because large regions of the frame share the same background color. LZW exploits these repeating pixel sequences by building a code table of recurring patterns. A typical 80×24 character frame at 8×16 pixel cells (640×384 px) with 2 colors may compress to under 2 KB per frame. Adding more colors or noise (dithering, gradients) increases entropy and reduces compression ratio.

The encoder normalizes all frames to the maximum column width and maximum row count found across every frame. Shorter lines are right-padded with spaces, and frames with fewer rows receive blank lines at the bottom. This ensures every frame renders at identical pixel dimensions, which is required by the GIF89a specification for proper playback without visual artifacts.

The canvas text renderer supports any character your browser's monospace font can display, including Unicode box-drawing (U+2500 - U+257F), block elements (U+2580 - U+259F), and most symbols. However, emoji and CJK characters often have double-width metrics that break the fixed-width grid assumption. Stick to characters that render at exactly one cell width in a monospace font for correct alignment.

The GIF specification requires a minimum code size of at least 2 bits, even for images with only 2 colors (which would theoretically need just 1 bit). This is because a code size of 1 would make the Clear Code equal to 2 and the initial code width 2 bits, which creates ambiguity in some decoder implementations. Using a minimum of 2 ensures the color table has 4 entries (indices 0-3, with 2-3 unused) and the initial code width is 3 bits, providing unambiguous decoding.

Smooth ASCII animation relies on incremental character changes between frames. Move objects by one character position per frame rather than jumping. Use intermediate characters for motion blur: a moving dot might use "." then "o" then "O" then "o" then ".". At 10 fps (delay of 10 centiseconds), this produces visually fluid motion. For rotation effects, pre-compute lookup tables of characters by angle: "-", "\", "|", "/".