Slack renders HTML attachments now. That is not the same as sharing them.

What changed

The change is narrow. Attach a complete HTML file to a Slack message and, in workspaces where this is live, it renders as a page in the channel instead of appearing as a download or being shown as code. You see the result, not the tags. For most people that is the friendlier behavior: the markup was never the point, the rendered page was. It mirrors what AI clients already do when they build a page and show it live rather than as source.

Two caveats keep this honest. It is rolling out, so it is not yet something you can rely on every recipient seeing. And it is about attachments specifically, a standalone .html file, not code you paste into a message, which still shows as text. So if you are seeing this for the first time, it is the file-preview path that changed, not Slack's message formatting.

Render and share are different problems

The change is worth noticing because it sharpens a distinction people blur constantly. Rendering is a viewer. Sharing needs a link.

Rendering answers "what does this look like" for the people already in the room. It is local to the surface you are on: the page is painted into your Slack client, for the members of that channel. Nothing about it produces an address. Sharing is the other problem entirely. It is about giving the page a stable URL, deciding who is allowed to load it, and making sure it keeps working once the message has scrolled away. Rendering an attachment inline solves the first and touches none of the second.

This is the same shift happening across every tool that now previews HTML: the bottleneck has moved off "can I see it" and onto "can I send it." Slack rendering an attachment makes the file look finished. It does not make it sendable.

What a rendered file in a channel still cannot do

Once an HTML file renders in a channel, it is easy to assume the sharing problem is handled. It is not. The rendered file still cannot do the things sharing actually means:

• Travel outside the workspace. A Slack file lives inside Slack. A client, a contractor, or anyone without a seat cannot open it. There is no external link to send.
• Go to one specific person. Everyone in the channel sees it, and anyone added later can scroll back to it. There is no way to scope it to a single recipient.
• Carry access controls. No password, no expiry, no email-domain gate. The only boundary is workspace membership, which is the wrong granularity for most things worth sharing.
• Stay findable. A message is a moment in a scroll. A week later the rendered page is buried under a thousand others, with no stable address to return to.

None of this is a knock on the feature. Inline rendering is a good preview. It is just a preview, and treating it as distribution is where the trouble starts.

Why this keeps coming up: agent output

The reason a small Slack change drew a long thread is that Slack has quietly become the place people dump agent-made HTML. An assistant builds a page, a report, a dashboard, a one-off tool, and the fastest way to get it to a colleague is to drop the file into a channel. The render makes that feel even more natural: paste, and there is the page.

But the thing people are sharing is exactly the thing that needs a real link. Agent output is frequently meant for someone specific, often someone outside the workspace, and often something you want to gate or expire. A channel is the wrong container for it. The render lowers the friction of the dump without fixing the part that was actually missing, which is a private, sendable address for the page.

Turning the file into a private link

Full disclosure: we build Stacktree, so read this as us describing where we fit, not neutral advice. The render-versus-share line above is the exact place we sit.

Stacktree has a Slack app for precisely this last mile. On any message that has an HTML file, a one-click action publishes the file to a private, unguessable URL, where the URL is the credential, so the viewer needs no account and does not have to be in your workspace. You can add a password, an email-domain gate with magic-link verification, or an expiry. Installing it needs no account. The result is a link you can send anywhere, that keeps working after the message scrolls away, and that the right people can open while everyone else cannot.

The two are not in competition. Slack rendering the attachment lets the channel see the page; Stacktree gives that same file an address so it can leave the channel. The page is a snapshot, and a snapshot on a private link is what most "can you send me that" requests are really after. It also sits in the gap between two bad defaults: a file locked inside a workspace, and a fully public link anyone can find. A private, unguessable URL is the option in between.

What to watch

This reflects behavior observed in mid-June 2026 from a public thread, during a rollout, not a documented spec. A few things would shift it:

1. Full rollout. Right now you cannot count on every recipient seeing the render. When it is universal, the preview becomes reliable, but the sharing limits above do not change.
2. External access. The meaningful move would be Slack letting a file leave the workspace on a controllable link. If that ships, the gap narrows, and the thing to read closely is what gating it offers and whether it is private by default.
3. How code-versus-page is decided. The render keys off the attachment looking like a complete page. If Slack formalizes a render-or-show-source choice, the "just let me read the file" path gets cleaner.

For now the state of play is easy to hold in your head: Slack is learning to render HTML attachments, which is a better viewer, and viewing has never been the same thing as sharing.