Bug: Extensionless log streams can be rendered as CSV tables

[SHAI-shivansh-sharma]

Bug

Extensionless plain-text log streams can be detected as CSV and rendered as a one-column Markdown table.

Reproduction

Given a log-like stream with no filename or extension:

2026-09-12 18:00:01 INFO boot ok
2026-09-12 18:00:02 ERROR disk full

Running through stdin/stream conversion can produce:

| 2026-09-12 18:00:01 INFO boot ok |
| --- |
| 2026-09-12 18:00:02 ERROR disk full |

Expected behavior

When there is no filename, extension, MIME hint, or CSV-style delimiter evidence, decodable plain text should stay plain text instead of being rendered as a CSV table.

Extensionless comma-delimited CSV should still convert to a Markdown table.

Notes

This appears to be a content-detection precedence issue rather than a missing file-extension mapping. Magika can infer text/csv for extensionless text, and CsvConverter currently accepts that before PlainTextConverter can use the detected charset.

[L4XB]

Not a maintainer. I measured this on 5640da7 before writing a patch, and both commands in the request already work today, so the change may be a no-op — details below so you can decide rather than take my word.

$ cat schema.sql
CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  email TEXT NOT NULL
);

$ markitdown schema.sql
CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  email TEXT NOT NULL
);

$ markitdown app.log
2026-09-12 18:00:01 INFO  boot ok
2026-09-12 18:00:02 ERROR disk full

Same through the API, and no renaming or stream metadata needed:

>>> MarkItDown().convert("schema.sql").markdown
'CREATE TABLE users (\n  id INTEGER PRIMARY KEY,\n  email TEXT NOT NULL\n);\n'
>>> MarkItDown().convert_stream(io.BytesIO(sql), file_extension=".sql")  # OK
>>> MarkItDown().convert_stream(io.BytesIO(sql), file_extension=".log")  # OK
>>> MarkItDown().convert_stream(io.BytesIO(sql), file_extension=".weird")  # also OK

The reason .weird works too is the first branch of PlainTextConverter.accepts:

if stream_info.charset is not None:
    return True

MarkItDown's own pipeline sets a charset for anything that decodes as text, so ACCEPTED_FILE_EXTENSIONS is only reached when there is no charset and no text/* mimetype. That is why the list can be short and still accept every text file the CLI is given.

Where the list does show: a caller that builds a StreamInfo itself and calls the converter directly.

>>> conv = PlainTextConverter()
>>> conv.accepts(io.BytesIO(sql), StreamInfo(extension=".sql"))   # False
>>> conv.accepts(io.BytesIO(sql), StreamInfo(extension=".log"))   # False
>>> conv.accepts(io.BytesIO(sql), StreamInfo(extension=".txt"))   # True

So adding the two extensions would make accepts() truthful for that caller, and would change nothing for the CLI or MarkItDown.convert*. Worth a line if you consider that answer part of the converter's contract; worth closing if ACCEPTED_FILE_EXTENSIONS is deliberately a fallback hint rather than a catalogue, since .yaml, .ini, .conf, .py and friends would have the same claim on it.

One thing I did find that is actually wrong, and it is not about extensions. With no extension at all, a log file on stdin is guessed as CSV and rendered as a table:

$ markitdown < app.log
| 2026-09-12 18:00:01 INFO  boot ok |
| --- |
| 2026-09-12 18:00:02 ERROR disk full |

Any extension makes it plain text again (markitdown -x .log < app.log, markitdown app.log, and even markitdown commas.log on a comma-separated log). Happy to file that separately if it is not already known — it is a detection-precedence question rather than anything the extension list can fix.

AI disclosure: measured and written by Claude (Anthropic) under my review; no human reviewed it besides me.

[SHAI-shivansh-sharma]

afourney Hi maintainers, I updated both the issue and PR after feedback showed the original extension-list change was not the real user-facing gap.

The PR now focuses on the actual bug: extensionless plain-text/log streams can be inferred as CSV and rendered as a one-column Markdown table. The fix keeps real/explicit CSV behavior intact, including extensionless comma-delimited CSV, and adds focused regression coverage for both cases.

Tests passing locally: 21 passed

PR: #2475

[afourney]

Thanks for reporting and investigating Shivansh and Lukas. I'll have a look this morning at both the PR and the issue. I'm wondering if magika is misidentifying it.