Image to ASCII conversion is a local, deterministic process that turns the visible tones of one decoded bitmap into a grid of ordinary text characters by resizing the source image to a chosen output width, sampling exactly one pixel per output cell, and mapping each sample's relative luminance to a fixed ten-character density ramp that runs from @ through progressively lighter symbols to a space. The output is visual ASCII art: it is not OCR, not captioning, and not text extraction. Every glyph in the result corresponds to one sampled pixel of brightness, which is why the final block can be copied as plain text, saved as a TXT file, or pasted into any chat, document, or terminal that accepts characters. Because decoding, resizing, sampling, and luminance calculation all run inside the current browser tab, the original image and the generated text never leave the user's machine, and nothing about the source compressed file, its color profile, its metadata, or its animation timing is preserved in the resulting string. That combination of a fixed ramp, single-pixel sampling, and pure local processing is what defines image-to-ASCII conversion in this context.
What Image to ASCII Conversion Actually Does
The conversion takes exactly one bitmap, decodes it, and produces exactly one block of text. Everything in between is a fixed pipeline: resize to the chosen column count, read one RGBA sample per output cell, composite the sample over white, convert the result to relative luminance, and pick one of ten glyphs from a density ramp. The output contains only the chosen glyphs and the newline characters that separate rows; it carries no color, no transparency, no animation, and no embedded profiles from the source file. Because every cell is a single character, the output is bounded by character count rather than pixel count, which is why a tall image at a wide column setting can hit a hard text limit even though its decoded pixel area looks modest.
It is important to separate this from adjacent techniques. Image to ASCII does not recognize letters, words, objects, or any semantic content already present in the picture. If the source shows a photograph of a printed page, the result is a textured gray field shaped like that page; it is not the text the page was carrying. The same is true for QR codes, captions, watermarks, or anything else you might read with your eyes. The conversion only knows brightness, and brightness is the only thing it can represent.
The Luminance Formula That Picks Each Character
Each output cell is decided by a short, well-defined calculation that begins with the sampled pixel and ends with one of ten ramp positions. The browser draws the source image into a small Canvas whose dimensions exactly match the planned ASCII columns and rows, fills the canvas white so transparent areas have a declared background, and uses high-quality image smoothing to perform the resize. The resize is browser-implemented, so the exact resampled pixels can differ slightly between engines, especially for high-frequency patterns or aggressive reductions; the algorithm that follows is deterministic regardless of those small differences.
From the resized canvas, getImageData returns one RGBA sample per output cell. Alpha is composited over white, then each sRGB channel is linearized with the standard W3C relative-luminance transfer function. The luminance value is calculated as 0.2126 R + 0.7152 G + 0.0722 B, so green pixels carry more weight than red, and red carries more weight than blue. The resulting value from zero through one is multiplied by nine and rounded to choose one of ten ramp entries. Dark samples land near the start of the ramp, bright samples near the end, and mid-gray samples land near the middle. Reverse mode simply maps index 0 to the last ramp character and index 9 to the first, so a bright sky that prints as spaces in normal mode prints as @ in reverse mode.
You can see the resampling step and the per-pixel read step documented in the MDN reference for drawImage and in the MDN reference for getImageData; those are the two browser primitives that the conversion depends on.
How Output Width and Row Count Are Computed
The output width you enter is a strict base-10 whole number from 10 through 200. Values outside that range fail instead of being clamped, and forms like +120, 120.0, 0120, or 1.2e2 are rejected. The number of rows is then computed from the source aspect ratio, with an explicit correction for the shape of a monospace character cell.
Ordinary monospace glyphs are roughly twice as tall as they are wide, so the row calculation multiplies image height divided by image width by your output width and then by 0.5. The result is rounded to the nearest whole row with a minimum of one. For an 800×600 source at an output width of 100, that gives round(600 ÷ 800 × 100 × 0.5) = round(37.5) = 38 rows, which produces 100 × 38 + 37 newline characters = 3,837 characters of total serialized output. The same image at the maximum width of 200 would produce round(600 ÷ 800 × 200 × 0.5) = round(75) = 75 rows, for 15,074 characters.
The 1:2 cell assumption is a practical preview approximation, not a measurement of the font you will eventually use to display the art. A different monospace face, line height, terminal, editor zoom, or letter spacing can make the downloaded block look taller or shorter than the preview did. When visual fidelity matters, render the TXT file in a known monospace font before judging the aspect ratio.
The Density Ramp and What Reverse Mode Changes
The fixed ramp has exactly ten entries. The first is the densest character, @, and the last is a space; the eight entries between are progressively lighter symbols chosen so that the visible density of the glyph tracks the brightness bucket it represents. Reverse mode uses the same ten characters in the opposite order, so index 0 maps to the space and index 9 maps to @. That single swap is useful when the ASCII art is meant to sit on a dark background, where the normal ramp would leave the bright regions of the source invisible.
| Position in the ramp | Normal mode intent | Reverse mode intent |
|---|---|---|
| First character (darkest output) | Densest symbol (@) | Lightest symbol (space) |
| Middle characters | Progressively lighter symbols | Progressively denser symbols |
| Last character (brightest output) | Lightest symbol (space) | Densest symbol (@) |
Switching ramp direction does not change any other part of the pipeline. The source image, the resize, the alpha compositing, the luminance formula, and the row calculation are all identical. Only the final lookup table flips.
Convert a Local Image into ASCII Text
The conversion is intentionally short. Open the Image to ASCII tool in your browser, then follow the three steps below.
- Choose one PNG, JPEG, GIF, or WebP file within the visible encoded and decoded limits. The browser has to actually decode the file before conversion can run. A matching extension or MIME type only passes the initial format screen; malformed content or unsupported codec profiles still fail at decode time and produce no ASCII output.
- Enter a whole output width from 10 through 200 characters and optionally reverse the fixed density ramp. The width field rejects anything that is not a plain base-10 integer; reverse mode is a single toggle that flips the ramp lookup for the next generation.
- Generate the complete ASCII result, then copy the visible text or download the local TXT file. The preview and the download are produced together from the same generation, so the TXT always matches what you see. Editing the width, the ramp direction, or the source image revokes the previous download URL and clears the prior result and copy state, so a stale block cannot be saved by accident.
Limits That Decide Whether Conversion Succeeds
Several limits interact, and failing any one of them aborts the conversion without producing partial output. The tool reports the specific limit that was hit and clears any previous result.
| Boundary | Value | Why it exists |
|---|---|---|
| Encoded file size | Up to 15 MiB | Keeps very large compressed files from being decoded at all. |
| Decoded side length | Up to 8,192 pixels | Caps any single dimension of the fully decoded bitmap. |
| Decoded pixel area | Up to 24,000,000 pixels | Bounds total decoded memory regardless of aspect ratio. |
| Output width | 10 to 200 characters | Strict integer only; values outside the range are rejected, not clamped. |
| Total serialized output | Up to 50,000 characters (including newlines) | Tall aspect ratios at valid widths can still exceed the budget and abort. |
The decoded limits protect the browser from unexpectedly large decoded memory when a compressed file is small but its bitmap is not, and the 50,000-character limit protects the resulting TXT from ballooning past what the copy step and the download step can handle. Exact helper tests anchor the boundaries: width 10 and width 200 are accepted, 9 and 201 are rejected, 50,000 characters is accepted, 50,001 is rejected.
Where the Conversion Runs and Why That Matters
Every step runs in the current browser tab. Decoding prefers createImageBitmap when that API is available; the resulting ImageBitmap is closed on replacement, on stale completion, or when the component unmounts. If createImageBitmap is not available for the file, a short-lived local Object URL loads an Image element and is revoked after load or failure. In the fallback path, the decoded frame is snapshotted to Canvas immediately, so an animated GIF cannot keep changing underneath the controls while you edit width or ramp direction.
Source dimensions are validated independently of the output controls, so changing the width while asynchronous decoding is still in progress cannot make an old width decide whether the image is accepted. Copy operations are guarded by a generation counter and a mounted-state check, so an older Clipboard promise cannot restore a "Copied" indicator after a later edit. Copy timers are identity-checked and canceled when replaced or unmounted, and download Object URLs are revoked on replacement and unmount as well. The image, its pixels, the generated text, and the filename never leave the browser, which is why the TXT output contains only ASCII characters and newline separators and nothing else.