Readable Markdown for documents, PDFs, spreadsheets, HTML, and knowledge-base workflows.
support@mdforall.com
About
A small conversion utility built around readable output and clear limits
Markdown For All turns common office, web, data, and PDF files into Markdown that can be reviewed in a text editor, documentation system, repository, or knowledge-base workflow. It is designed as a practical conversion step, not as a promise of perfect document reconstruction.
Why this project exists
Many documents outlive the software or layout they were created in. A policy written in Word may need to move into a documentation repository. A table may need to become a small Markdown reference. A saved HTML page may need its article text without navigation and scripts. A PDF may be the only remaining copy of a report that now needs to be searchable or reviewed in plain text.
Markdown For All is maintained as a small independent software project for that transition. The project focuses on preserving the structures that travel well—headings, paragraphs, lists, links, quotes, code, and simple tables—while explaining where page layout, visual design, formulas, or scanned content require additional work.
Who is responsible for the service
The public operator identity for support and service issues is Markdown For All. The same project maintains the converter, public documentation, privacy disclosures, format guidance, and abuse protections. Support, privacy, security, and reproducible conversion reports can be sent to support@mdforall.com.
This site does not claim to be a large company, an enterprise document-management platform, or a certified archival service. Its scope is narrower: provide a working conversion utility, publish realistic limits, respond to material problems, and avoid presenting uncertain output as authoritative.
What the converter is designed to do
The service accepts common source formats including DOC, DOCX, XLS, XLSX, CSV, PPT, PPTX, PDF, HTML, JSON, XML, TXT, and supported ZIP archives. It returns Markdown intended for editing, documentation, content migration, repository review, and low-risk knowledge-base preparation.
The result should be treated as a structured draft. A clean DOCX with real heading styles can convert very well. A multi-column PDF with custom fonts may need substantial review. A workbook with merged cells, formulas, charts, hidden rows, and pivot tables cannot be represented faithfully as one Markdown table. The format pages explain these differences before a user uploads a file.
How the public service is built and checked
The public site uses a static HTML, CSS, and JavaScript interface with a Go conversion API. The browser sends a selected file to the API, the API writes it to temporary storage for the active request, runs the relevant converter, returns Markdown, and removes the temporary file. The service does not require a user account or maintain a personal document library.
| Area | Project responsibility | User responsibility |
|---|---|---|
| Conversion | Return a readable Markdown draft and document known format limits. | Compare the result with the source before publishing or relying on it. |
| File handling | Use temporary request storage and avoid ordinary application logging of document bodies. | Remove secrets and use an approved private workflow for sensitive material. |
| Incident reports | Prioritize security, privacy, broken routes, and reproducible conversion failures. | Provide a sanitized test file and enough steps to reproduce the issue. |
What the service does not promise
- • It does not promise pixel-perfect reproduction of a source document.
- • It does not treat generated Markdown as automatically correct for legal, financial, medical, or compliance use.
- • It does not use uploaded file contents to train AI models or build marketing profiles.
- • It does not require an account for the basic conversion workflow.
- • It does not place ads inside upload, convert, copy, download, or result controls.
- • It does not recommend public uploads for confidential or regulated documents.
File handling and appropriate use
Uploaded files are sent to the conversion API, written to temporary server storage for processing, and deleted after the response is returned. The generated Markdown is sent back to the browser and is not intentionally added to a document library. Operational systems may record request metadata such as time, IP address, status code, file size, extension, processing duration, user agent, and error type. The project is configured not to log the uploaded document body or generated Markdown body as ordinary application logs.
This workflow is intended for public, low-risk, redacted, or already-shareable material. Contracts, credentials, customer exports, health information, bank records, private source code, HR files, and other regulated material should use an approved private or self-hosted process. No internet service can promise absolute security, so the safest sensitive upload is the one that is not made.
Maintenance priorities
Work is prioritized in this order: privacy and file-handling defects, security and abuse reports, reproducible conversion failures, broken public routes or incorrect status codes, misleading documentation, and then lower-impact format improvements. Reports are more useful when they include the affected URL, source format, approximate file size, browser, operating system, expected structure, actual structure, and a sanitized sample that does not expose private data.
Format guidance is updated when a converter limitation changes or when a recurring failure pattern becomes clear. The site may be supported by advertising, but advertising does not alter conversion output and must remain visually separate from the tool controls.
Last operational-content review: July 15, 2026.
How we verify changes
Public releases are checked for reachable routes, real 404 status codes, canonical URLs, sitemap consistency, visible file-handling language, and working converter controls. Converter changes are tested with small low-risk source files for text, CSV, JSON, XML, HTML, PDF, DOCX, XLSX, PPTX, and ZIP workflows when the required test toolchain is available.
- • High-risk details—names, dates, totals, clauses, identifiers, and table rows—must be compared with the source.
- • Static assets and machine-readable resources are validated before packaging.
- • Privacy regressions include temporary-file cleanup and scans for embedded personal records.
- • Production routing checks cover HTTP, www, canonical redirects, 404 responses, robots, sitemap, ads.txt, and release headers.
Known limits we track publicly
The project keeps a central conversion limits page instead of hiding format boundaries inside marketing copy.
- • Scanned PDF OCR is not part of the basic public workflow.
- • Multi-column PDF reading order and custom-font mapping can fail.
- • Spreadsheet formulas, charts, pivots, macros, and hidden data are not executable Markdown.
- • Slide design, animation, diagram relationships, and timing are not reproduced.
- • JavaScript application shells may not contain the article text needed for HTML conversion.
Public change record and review cadence
Material changes to conversion behavior, file handling, public routes, and documentation are recorded in the public changelog. Core format guidance is reviewed when behavior changes or recurring failure evidence appears; operational and trust content is reviewed at least quarterly.
Last reviewed: July 17, 2026. Next scheduled operational-content review: October 2026.