About

ASCII art encodes visual information within a fixed-width character grid, typically 80×40 cells. Each cell maps to a single glyph from the printable ASCII range (0x20 - 0x7E). The visual density of a character determines its perceived brightness: @ registers as near-black while . reads as near-white. Getting character density wrong collapses contrast and produces unreadable output. This editor provides Bresenham-based line rasterization, BFS flood fill, and rectangular selection so you work at the glyph level without guessing pixel alignment. Grid state persists to LocalStorage automatically.

The tool approximates a bitmap editor but operates in discrete character space. Diagonal lines exhibit staircase artifacts inherent to low-resolution grids. For best results, work at grid widths above 60 columns and use high-density characters (#, @, M) for foreground and low-density characters (., ·, ) for background. Export assumes a monospace font at 12px line height.

Formulas

The editor uses Bresenham's line algorithm to rasterize straight lines between two grid coordinates. Given start point (x₀, y₀) and end point (x₁, y₁), the algorithm steps through the major axis and accumulates error to decide when to step on the minor axis.

d_x = |x₁ − x₀|
d_y = −|y₁ − y₀|
err = d_x + d_y
Loop: if 2err ≥ d_y → err += d_y, x += s_x
if 2err ≤ d_x → err += d_x, y += s_y

The flood fill uses Breadth-First Search. Starting from cell (x, y), it enqueues all 4-connected neighbors that match the target character and replaces them with the fill character. Worst-case time complexity is O(W × H) where W and H are grid width and height.

Where d_x = horizontal distance, d_y = vertical distance, err = accumulated error, s_x = step direction on x-axis (+1 or −1), s_y = step direction on y-axis.

Reference Data

Character	Hex Code	Relative Density	Common Use
@	0x40	0.95	Maximum fill / dark regions
#	0x23	0.90	Walls, borders, dense fill
M	0x4D	0.85	Heavy shading
W	0x57	0.83	Heavy shading alternate
%	0x25	0.70	Medium-dark texture
&	0x26	0.68	Medium shading
*	0x2A	0.50	Stars, medium fill
+	0x2B	0.40	Crosshairs, joins
=	0x3D	0.38	Horizontal lines, water
-	0x2D	0.25	Horizontal lines
\|	0x7C	0.25	Vertical lines, pipes
/	0x2F	0.22	Diagonal lines (right-leaning)
\	0x5C	0.22	Diagonal lines (left-leaning)
:	0x3A	0.18	Light vertical texture
;	0x3B	0.17	Light texture
,	0x2C	0.10	Very light shading
.	0x2E	0.08	Minimal fill, highlights
`	0x60	0.05	Near-white accent
(space)	0x20	0.00	Empty / background
~	0x7E	0.30	Water, waves
^	0x5E	0.15	Mountains, carets
_	0x5F	0.12	Underlines, ground
!	0x21	0.30	Exclamation, rain
"	0x22	0.20	Light texture pairs
'	0x27	0.07	Apostrophe, minimal mark

Frequently Asked Questions

Each printable ASCII character occupies identical cell space in a monospace font, but covers different amounts of that cell with ink. Characters like @ and # fill roughly 85-95% of the cell area, reading as dark. Characters like . and ` cover under 10%, reading as light. Contrast in ASCII art depends entirely on selecting characters with sufficient density difference - a minimum delta of 0.40 between foreground and background characters produces readable results at standard viewing distances.

ASCII art operates on a discrete grid where each cell is approximately twice as tall as it is wide (typical monospace aspect ratio of 1:2). Bresenham's algorithm places one character per step along the major axis, producing staircase patterns on diagonals. This is an inherent limitation of character-cell resolution. Using / and \ characters for 45-degree angles partially compensates because their visual slope matches the grid aspect ratio. For other angles, staircase artifacts are unavoidable without increasing grid resolution.

Terminal displays typically support 80 columns by 24 rows. Email-safe ASCII art should stay under 72 columns to avoid line wrapping. Forum signatures commonly use 60×10. For detailed artwork, 120×60 or larger provides enough resolution for recognizable portraits. The editor caps at 200×100 to maintain browser performance - DOM tables beyond that size cause noticeable input lag.

The BFS flood fill checks 4-connected neighbors (up, down, left, right - no diagonals). A region must be fully enclosed by characters different from the target character to contain the fill. A single gap in the boundary causes fill to leak through and flood the entire connected area. Diagonal gaps do NOT cause leaks since the algorithm only checks orthogonal neighbors. Always verify boundary continuity before applying fill to large regions.

Yes. Use the Import button to paste existing text. The editor parses the text line by line, mapping each character to its corresponding grid cell. Lines shorter than the grid width are padded with spaces. Lines exceeding the grid width are truncated. The grid automatically resizes to fit the imported content's dimensions, up to the maximum of 200×100 cells.

The history stack stores up to 100 snapshots. Each snapshot is a full deep copy of the grid array. At 200×100 grid dimensions, each snapshot consumes approximately 20 KB of memory, so the maximum history footprint is roughly 2 MB. When the stack exceeds 100 entries, the oldest snapshots are discarded. Redo history is cleared whenever a new edit is made after an undo operation.