What Slack does with a Markdown file, and where a web page fits
Slack takes Markdown through a message, or a file upload that keeps the text searchable, and that is the door this page is about. The question worth asking is what a web page looks like by the time it arrives, because Slack never sees the page itself. It sees whatever the conversion handed over, and nothing else.
Slack renders a documented subset, bold, italics, quotes, lists and code, and nothing at all beyond it. What comes out of a web page here is the article text as headings and paragraphs, with the links rewritten as Markdown links rather than dropped, so the structure Slack is looking for is actually present instead of merely implied. That is the entire trick, and there is nothing clever underneath it.
What survives from a web page into Slack
The conversion drops navigation bars, cookie banners, related article rails and the newsletter box before Slack ever sees them, because none of it carries meaning into Slack and all of it costs something. What it keeps is the part you would otherwise have retyped by hand.
- The real title of the page comes through, not the title the tab was showing, and Slack receives it as structure rather than as something to infer.
- The body text arrives in reading order, with its heading levels intact, which is the part Slack would otherwise have to reconstruct on its own.
- Links are rewritten as Markdown links instead of being flattened into bare words, so nothing downstream of Slack has to guess at it.
What Slack never gets back from a web page
Every conversion costs something, and a page listing only the gains is a sales page. Here is what a web page gives up on the way to Slack, stated plainly enough that you can decide against it.
- The layout goes, and with it every image that carried no text of its own, and Slack will not get it back from anywhere.
- Anything the page draws after the first paint may never be seen at all, so nothing you build in Slack should depend on it.
- Whatever sits behind a paywall was never sent to us, so it cannot be recovered, which is a real cost inside Slack and not a rounding error.
The URL to Markdown step behind this Slack page was measured
our extraction layer does the conversion, and it was proven end to end on 30 August 2026: a live page came back in Markdown carrying its real title, its real text and its converted link, with the cache switched off so nothing was recycled. That is one run on one day and not an average, which is exactly why the date travels with the claim instead of being left out of it. The same output is what Slack would have received.
A page that assembles itself in the browser can come back thinner than it looks, and nothing in the output says which part never arrived. Slack has no way of telling you any of that from the inside, so it gets said here instead, on the page that sent you there.
Once the page is Markdown, what to do inside Slack
With the Markdown in hand, post the short version in the message and attach the full Markdown file beside it. That is a Slack habit rather than a conversion setting, and it is where most of the value of converting a web page in the first place actually lands.
The constraint worth knowing before you start: headings and tables are outside that subset, so they arrive as plain lines of characters. It bites the same way whether the Markdown came out of a web page or out of something else entirely, but it bites hardest on long documents, which is what a web page usually is.
What we will not pretend about URL in Slack
- Slack will not render a table, now or ever, and converting a web page first does not change that in the slightest.
- a converted table pasted into a message becomes a wall of pipe characters, which is a Slack behaviour rather than anything the page conversion did.
- The conversion costs half a credit and the price is shown before the page is sent, whether the Markdown ends up in Slack or nowhere at all.