Markdown export needs a policy for attachments
Action Text's Markdown conversion raises a practical export question: which formatting survives, how attachments are represented and who can open links.
By 
Paul. Languages and frameworks
A useful Markdown export explains what the receiving person or application can recover from the document. Converting rich text means choosing representations for formatting, structure and attached files. Removing HTML tags is not enough to define that agreement. An attachment reference may survive as a link while the recipient still cannot open the file. Export quality includes both representation and the access boundary around it.
The 28 February 2026 Rails roundup reported Action Text's to_markdown conversion and a separate change for blob links. The initial conversion proposal, PR 56858, was merged on 24 February. Looking back at the week beginning 25 February, the important distinction is between that initial conversion work and the later attachment-link improvement. They should not be described as one initial merge.
Conversion defines a receiving format
The roundup described conversion across the Action Text stack, including content, fragments, rich text and attachments. It listed formatting and block structures among the supported inputs. That establishes the direction of the change: structured rich-text content can be represented as Markdown. It does not establish that converting to Markdown and back reconstructs every part of the original document. The dated Rails summary is evidence of development work, rather than a claim about a stable release installed in an application.
For a hypothetical document containing headings, a list and an embedded file, a recipient may need the headings and list to remain recognizable while accepting a simple file reference. Another recipient may need the document to look exactly as it did in the editor. Those are different requirements. The export should state which one it serves before an implementation is judged against the other.
Markdown cannot preserve every possible HTML structure and presentation choice. An application's custom attachment may also carry meaning that a generic link cannot express. The useful promise is therefore a defined conversion, with stated losses where necessary. Calling the result “portable” should explain what the recipient can do with it, rather than imply identical behavior in every renderer.
Attachment links were a separate improvement
The roundup said that, when a rendering context is available, blob attachments can produce Markdown image links or ordinary links instead of plain-text placeholders. That condition matters. A rendering context can supply information needed to construct an address. A conversion performed elsewhere may not have the same context. The existence of to_markdown alone should not be presented as a guarantee that every attachment always becomes a usable URL.
The separation also matters historically. The roundup placed the attachment-link item beside the initial conversion item. Later work can improve an interface without having been part of the first implementation. Readers assessing a dependency need to know which behavior belongs to which change. This article does not infer a released Rails version from a weekly report about development activity.
For the same reason, moving documentation on the main branch is not a release record. It may describe work newer than an application's dependency. Before planning an integration, a team should establish the exact code version it intends to use and the behavior available there. The February discussion supplies a design question worth asking; it does not prove the answer for an unspecified stable version.
An address is not authorization
A Markdown link contains a destination, not a general grant of permission. A file may require authentication, depend on a particular application's routing or have a limited period of availability. These are possible access conditions, not claims about the behavior of every Action Text URL. The export contract should make the conditions for its own attachments explicit.
Consider a hypothetical report exported from a tenant-scoped application. The person allowed to read the report might not be allowed to share every attached file with someone outside that tenant. Authorization should be checked before producing the export and again where the application serves protected resources. Passing a record identifier into a conversion does not establish ownership. Changing the output format should not silently widen the audience.
Likewise, copying a protected link into a public document can expose information about a resource even if the bytes remain inaccessible. Review where exports and their logs will go. A readable Markdown file may travel farther than the application screen from which it was produced. That is a reason to define attachment handling with the receiving use case in mind, rather than an argument against exporting at all.
Plain text can be sufficient
The strongest counterargument is that some consumers do not need Markdown. A simple index may need searchable words and a stable reference to the original record. If formatting adds no useful information for that consumer, plain text may be easier to reason about. Exporting more structure can introduce rendering and attachment questions without answering a real requirement.
Other consumers genuinely benefit from headings, lists and links. The decision should follow what they need to preserve. Search indexing, document editing and human-readable handover can each require different representations. A single “export” label should not conceal those differences. Defining them lets the team choose whether one format is sufficient or several separate exports are appropriate.
For custom software development, agree on a small representative document set before treating conversion as complete. Include formatting the recipient needs and an attachment whose access conditions are known. Such examples are proposed acceptance material, not a hands-on test reported here. The February Action Text work makes a useful boundary visible: a document is ready to leave an application only when its recipient can understand the representation and the limits of its links.