Pipefmt

| Name       | Age| Location      |Role| Started|
|---|---|---|---|---|
|Alice| 30 |New York| Engineer| 2019|
| Bob |25| San Francisco |Designer with a long title| 2021|
| Charlie | 35|London   | Manager|2017|

That is a real GFM table. Most online formatters reject it, lose header alignment, or stretch the wrong column. Pipefmt aligns it in roughly 4 ms, even when one cell holds "Designer with a long title" and another holds the kanji 設計者. Here is what the formatter does, where the non-obvious decisions live, and why the output sometimes still looks crooked in your editor.

The input that breaks every other formatter

Every hostile trait is on purpose. Some rows have outer pipes, some do not. Cells have mixed whitespace. The separator row uses bare ---, so column alignment is undefined and the formatter has to guess. The longest cell ("Designer with a long title", 26 characters) sits in row 3 of column 4, which breaks width detectors that only sample the first two rows.

During the build we ran Pipefmt against four alternatives: TableConvert, prettier-plugin-markdown, the markdown-table npm package, and a popular VS Code extension. Three of the four mismeasured column widths when the longest cell held a CJK glyph. Two stripped outer pipes silently.

What the formatter measures, column by column

Pipefmt runs four passes.

Pass one tokenizes. It splits each line on unescaped |, trims each cell, and records per row whether outer pipes were present. The flag is per row because pasted tables routinely mix styles in the same paste.

Pass two measures display width. Pipefmt walks every cell grapheme by grapheme with Intl.Segmenter and checks each one against the Unicode East Asian Width property (TR #11, revision 51). Characters tagged W (Wide) or F (Fullwidth) count as 2 columns; combining marks and zero-width joiners count 0 or 1. Skip this step and you get the single most common bug in browser-based markdown formatters.

Pass three resolves alignment. Explicit separator markers (:---, :---:, ---:) win. If the separator is bare --- and Align is set to Auto, Pipefmt picks right for columns whose every non-empty value parses as a number, left otherwise.

Pass four renders. Pipefmt pads each cell to column width, adds single-space gutters when Padding is on, and appends outer pipes when Outer Pipes is on. Total latency runs 1 to 4 ms for tables under 200 rows, measured live in the status bar.

How alignment markers survive the pass

Here is the same opener table after Pipefmt has finished:

| Name    | Age | Location      | Role                       | Started |
| :------ | --: | :------------ | :------------------------- | ------: |
| Alice   |  30 | New York      | Engineer                   |    2019 |
| Bob     |  25 | San Francisco | Designer with a long title |    2021 |
| Charlie |  35 | London        | Manager                    |    2017 |

Two things happened without being asked. Age and Started flipped to right alignment because every value parses as an integer, and the separator records that with --: so any GFM-compliant viewer renders the table the same way. The longest data cell set the width of column 4, padding every other row in that column to 26 characters.

Now add a CJK row:

| Name    | Age | Location      | Role                       | Started |
| :------ | --: | :------------ | :------------------------- | ------: |
| Alice   |  30 | New York      | Engineer                   |    2019 |
| 田中    |  29 | 東京          | 設計者                     |    2020 |
| Charlie |  35 | London        | Manager                    |    2017 |

The kanji cells (田中, 東京, 設計者) count as 4, 4, and 6 columns of visible width. Pipefmt's padding accounts for that, and any GFM-compliant CJK-aware renderer will draw the table square.

When the output still looks wrong in your editor

The most frequent complaint we get is that the formatted table still looks misaligned in the editor. Almost every report traces back to one of a handful of causes. The editor might be using a proportional font; switch to JetBrains Mono or Source Code Pro. The monospaced font might lack proper CJK metrics, which is common with older Consolas builds; Noto Sans Mono CJK fixes it for free. Mixed line endings can cause trailing-whitespace rendering that shifts perceived alignment by one column; normalize to LF. None of these are formatter bugs, but each looks like one until you name it. That is why Pipefmt's status bar surfaces column count, row count, and a "CJK detected" badge.