This file is a self-demonstrating example. Because it contains a line-initial trigger word plus non-ASCII characters (see the demo line at the bottom), dragging this file into any Slack channel uploads it as "Binary file" with no preview. That IS the bug.
The file-type classifier applied to uploaded files (rolled out ~June 2026) misclassifies plain-English Markdown files. Two compounding bugs:
-
Any file containing a word starting with
recordorprogram(e.g. the common English words "recording", "records", "programs") at the start of a line is classified as Pascal — even a file containing only that single word, and even when the rest of the file is 8 KB of unambiguous Markdown (headings, lists, fenced code blocks). The same words mid-sentence or quoted classify fine. These are exactly the tokens that canonically open Pascal constructs (program Foo;opens a source file,recordopens type declarations), suggesting the Pascal class is undertrained and line-initial occurrences of its signature tokens overwhelm all other evidence. Ordinary prose wrapping can land these words at a line start by accident. -
When that Pascal misclassification combines with any non-ASCII character anywhere in the file — emoji, em/en dash, section sign, multiplication sign, arrows, curly quotes — the verdict degrades to Binary and the file gets no text preview at all. Tested individually: each of U+1F334, U+2014, U+00A7, U+00D7, U+2192, U+2248 alone flips Pascal to Binary; the same characters without the Pascal trigger classify fine. Since typographic punctuation is near-universal in real prose (every smart-quote editor inserts it), in practice the Pascal misread almost always presents as "Binary file".
The .md extension appears to be ignored entirely.
Each row is the full contents of an uploaded .md file:
| File contents | Slack verdict |
|---|---|
recording |
Pascal |
recording + palm tree emoji (U+1F334) |
Binary |
recording … em dash (U+2014) |
Binary |
recording … section sign (U+00A7) |
Binary |
recording … multiplication sign (U+00D7) |
Binary |
recording … rightwards arrow (U+2192) |
Binary |
recording … almost-equal sign (U+2248) |
Binary |
logging |
Markdown |
logging + palm tree emoji (U+1F334) |
Markdown |
see § 4 for details (no trigger word) |
Markdown |
recording the PTO and each system's status: |
Pascal |
the PTO and each system's status: |
Markdown |
I enjoy recording things |
Markdown (mid-line: OK) |
"recording" |
Markdown (quoted: OK) |
records show the truth … |
Pascal |
recorded music changed culture … |
Pascal |
programs for kids fill up fast … |
Pascal |
procedures matter more than goals … |
Markdown |
units of measure confuse everyone … |
Markdown |
16 total across two rounds, all correctly Markdown, so the bug is Pascal-specific rather than a general long-tail-class problem.
Round 1 — line-initial keyword-PREFIX words from other languages: beginning (begin), importantly (import), defense (def), structured (struct), letting (let), packages (package), mystery (my), selecting (select).
Round 2 — line-initial EXACT signature tokens of other classes, in plain English sentences (much stronger bait than prefixes; still all Markdown):
| Opening line | Class it baits |
|---|---|
Given the timeline, … / When the server restarts, … / Then we decided … |
Gherkin |
Feature: dark mode is … / Scenario: a user logs in … |
Gherkin (exact keyword + colon) |
From what I can tell, … |
mbox (canonical From line) |
Require two approvals … |
Sieve |
[project update] notes … |
INI/TOML section-header shape |
An 8 KB internal runbook (.md) uploaded as "Binary file". Binary-search
bisection over ~7 upload rounds isolated the trigger to one prose-wrapped line
that happened to start with the word "recording"; follow-up rounds established
the line-position rule, the non-ASCII → Binary degradation, the
record*/program* generalization, and the Pascal-only scoping (~44 data points
total). A second in-the-wild hit confirmed the model: a 22 KB review doc whose
prose wrapping landed record. at the start of one line, with no emoji but
ordinary em dashes and section signs, uploaded as "Binary file". The
snippet-type picker lists ~150 classes (down to Brainfuck, Z80, MUMPS, Oz), yet
none of the others tested misfire on English prose; Pascal alone does.
All of these say the test files are text/markdown:
- file(1) / libmagic: "Unicode text, UTF-8 text", mime
text/plain - git: diffs as text
- Google Magika 1.x: "Markdown document (text)" for every file above, including the ones Slack calls Pascal/Binary
Any Markdown doc where prose wrapping lands "recording"/"records"/"programs" etc. at a line start loses its text preview; with any non-ASCII character present (an em dash, a curly quote, an emoji — near-universal in modern docs) it's treated as an opaque binary blob. This silently affects runbooks, meeting notes, READMEs; a file that starts with "programming tips" plus one em dash anywhere uploads as "Binary".
Slack desktop app on macOS, multiple workspaces, July 2026. Behavior is server-side (verdict identical across upload paths).
The next paragraph intentionally begins with the trigger word and contains an em dash — the exact combination this report describes. It is why this very file uploads to Slack as "Binary file":
recording — this line starts with the word "recording" and contains an em dash. Per the bug above, that is sufficient for Slack to classify this entire Markdown document as an opaque binary blob.
You're welcome! I also reported this to Slack last month when I created this.