The
Smart Markdown Formatter isn't calling AI at all. It is a deterministic JavaScript parser: it reads the text line-by-line, scores/recognises structural patterns, and applies Markdown rules. So the same input should produce the same output every time.
The current pipeline is essentially:
Raw text → normalisation → structural detection → classification → Markdown construction → optional safe HTML preview
1. Input normalisation
First it cleans the pasted text:
``
text
Windows line endings → \n
trailing spaces → removed
3+ blank lines → 2 blank lines
`
Importantly, the new version does not remove tabs. That's what fixed your ChatGPT tables.
For example, copied text may actually contain:
`
text
AreaTABImplementation
InterfaceTABFull-screen TXTWRK Tools overlay
TechnologyTABVanilla JavaScript
`
Those invisible tabs are valuable structural information.
2. Table-detection algorithm
This now has two table algorithms.
The first looks for consecutive tab-separated rows:
`
text
Area Implementation
Interface Full-screen overlay
Technology Vanilla JavaScript
`
Internally that's detected roughly as:
`
js
line.split(/\t+/)
`
If there are at least two columns and multiple consecutive rows, it treats the first row as the table headings.
It generates:
`
md
`
It works with three or more columns too, so:
`
text
Tool Main Functions Processing
Colour Picker HEX, RGB and HSL Browser
Text Counter Counts text Browser
`
becomes:
`
md
`
The second table algorithm recognises consecutive label/value pairs:
`
text
Technology: Vanilla JavaScript
Processing: Browser
Endpoints: None
Mobile: Yes
`
and turns those into:
`
md
`
So there are two independent ways of discovering tables.
3. Heading inference
The next algorithm tries to identify standalone section titles.
It looks at things such as:
`
text
TXTWRK Tools Development Report
Development Overview
Work Completed
Smart Formatting
Future Expansion
``
A candidate needs to be relatively short and
not look like a sentence, table row, bullet, numbered item or Label: value row.
Context then matters.
For example:
``
text
...end of the previous paragraph.
Future Expansion
•JSON formatter
•URL tools
``
Future Expansion is short, follows prose and precedes a list. That's strong evidence that it's a heading.
The first detected heading becomes:
``
md
TXTWRK Tools Development Report
`
and later headings become:
`
md
Development Overview
Work Completed
Smart Formatting
Future Expansion
``
So it isn't merely saying
"every short line = heading." It examines the surrounding structure as well.
4. Sentence/prose detection
There's also a basic
isSentenceLike() classifier.
A line is considered strongly prose-like when it has features such as sentence-ending punctuation:
``
text
The system runs entirely in the browser.
`
or is sufficiently long/wordy.
That prevents something like:
`
text
The architecture is deliberately expandable.
`
from accidentally becoming:
`
md
The architecture is deliberately expandable.
`
Instead it stays ordinary paragraph text.
5. Bullet-list recognition
Existing bullets are easy:
`
text
•Colour Picker
•Text Counter
•Text Cleaner
`
The algorithm recognises:
`
text
`
and normalises them to standard Markdown:
`
md
•Colour Picker
•Text Counter
•Text Cleaner
`
There's also an inference algorithm for unmarked lists.
Something like:
`
text
Colour Picker
Text Counter
Text Cleaner
Smart Markdown Formatter
`
can be recognised as a run of short related lines rather than four paragraphs.
When there are at least three suitable consecutive lines, it can produce:
`
md
•Colour Picker
•Text Counter
•Text Cleaner
•Smart Markdown Formatter
`
It's deliberately conservative because otherwise every collection of short headings could become a list.
6. Numbered lists
It recognises both:
`
text
1. First item
2. Second item
3. Third item
`
and:
`
text
1) First item
2) Second item
3) Third item
`
and produces normal Markdown numbering.
7. Paragraph reconstruction
Anything that hasn't matched a stronger structural rule eventually falls into the prose algorithm.
So:
`
text
The TXTWRK Tools project introduced a new collection of practical
browser-based utilities directly into TXTWRK.com.
`
can become one paragraph:
`
md
The TXTWRK Tools project introduced a new collection of practical browser-based utilities directly into TXTWRK.com.
`
But when the next line looks like a new heading, table, bullet list, numbered list or other structure, the paragraph terminates rather than swallowing that content.
8. Detection priority is important
The parser doesn't ask all the algorithms simultaneously. It uses an order of precedence.
Conceptually it's now:
`
text
READ LINE
│
├─ blank? ─────────────────────→ paragraph break
│
├─ tab-separated rows? ────────→ TABLE
│
├─ existing Markdown? ─────────→ PRESERVE
│
├─ repeated Label: Value? ─────→ TABLE
│
├─ bullet marker? ─────────────→ BULLET LIST
│
├─ number marker? ─────────────→ NUMBERED LIST
│
├─ heading-like + context? ────→ HEADING
│
├─ 3+ short plain lines? ──────→ INFERRED LIST
│
└─ otherwise ──────────────────→ PARAGRAPH
`
That priority is a major part of why the second version should perform better.
For example, this:
`
text
Area Implementation
`
could superficially resemble a short heading. But tabular detection happens first, so it gets consumed as part of a table before heading detection sees it.
9. It also preserves existing Markdown
If somebody pastes something that's already partly formatted:
`
md
Existing Heading
•Existing item
•Another item
`
the parser tries not to destroy it.
It recognises existing constructs including headings, blockquotes, fenced-code markers and Markdown-table rows.
10. Preview is a separate algorithm
FORMAT MARKDOWN and PREVIEW actually do two different jobs.
The formatter produces the Markdown text.
Then the preview parser takes that Markdown and converts the supported subset into HTML:
``text
heading →
heading →
1. item →
| table | →
bold →
italic →
code →
```
Before doing that, it
HTML-escapes the user's text. That's important because we're putting the preview into
innerHTML; pasted HTML shouldn't simply execute as page markup.
What makes it "smart"
It's essentially a
small rule-based document parser.
It doesn't understand the report semantically the way I understand it. Instead, we're exploiting the structural clues left behind when text is copied from something like ChatGPT:
tabs + blank lines + punctuation + line length + neighbouring lines + bullet characters + numbering + capitalisation + repeated column counts + label/value patterns.
Those clues together let it reconstruct a surprising amount of the original document structure.
And your failed example was useful because it exposed a specific missing signal:
tabs were carrying the original ChatGPT table structure, and our first algorithm wasn't using them. The revised version now does.
COMMUNITY
People