A technical writer resume should make the work easy to inspect: what you documented, who used it, how you checked it, and which parts you owned. An API reference, a field-service procedure and an internal knowledge base solve different problems. Name the actual deliverable before listing the software you used.

This guide includes a fictional software documentation resume, ways to describe writing and review work, and examples for adapting the same structure to other industries. Outcomes are useful when supported by evidence; a credible resume does not need a ticket-reduction percentage in every role.

Start with the document and audience. “Maintained authentication and error-handling reference pages for API integrators” gives more context than “created technical documentation.” Add the product or version scope, your review method, and any result you can substantiate.

The U.S. Bureau of Labor Statistics describes technical writing work that includes determining users’ needs, working with technical staff, preparing supporting material, and revising content. Use that as occupational context, then follow the responsibilities in the actual vacancy.

Show tools through their use: Markdown for source files, Git for version control, a publishing system for output, or an authoring environment for reusable topics. Structured authoring and docs-as-code can coexist. Neither the industry nor a tool name proves which workflow a team uses.

If you have shareable samples, link to a small selection with clear authorship and context. If your work is confidential, explain the available evidence without disclosing restricted content or implying you have permission to share it.

Fictional example: Claire Whitlock, the employers, education, projects, training and recognition below are invented to demonstrate resume structure. This is not a verified career history or hiring success story. Contact and portfolio addresses are placeholders. Replace every detail, including language ratings, with your own evidence.

The sample separates API reference work, release notes and support documentation, and describes review steps without manufacturing adoption or ticket-reduction results.

Use the vacancy to select relevant documentation, tool and review terms. The list below is an editorial checklist, not measured keyword frequency or an ATS scoring formula.

Use a term only where your experience supports it. A portfolio quickstart is not necessarily SDK documentation, and editing a generated reference page does not mean you designed its API. The resume keyword scanner can help you compare language; check any suggestion against your actual work.

Borrow the structure, not Claire’s credentials or experience. Your resume should connect each claimed skill to an employment, project, coursework or volunteer example with an accurate label.

A reverse-chronological work history is a practical default because it connects responsibilities to dates and employers. Career changers can put relevant projects or a concise skills section first while retaining a clear work timeline. Freelancers may group engagements under a freelance heading or list substantial contracts separately; state the relationship accurately.

Choose length according to relevant evidence and the application instructions, not a fixed number of career years. Remove repeated duties before shrinking text. See the one-page or two-page guidance for layout tradeoffs.

Use clear headings and inspect the exported file for reading order, clipped text and working links. Submit a format the employer accepts. PDF can preserve visual layout, but it does not guarantee successful parsing. Check extracted application fields when the system offers a preview. The ATS resume format guide explains practical checks.

Use the summary to identify your audience, document types and relevant workflow. Years are optional; if included, calculate them from the actual dates. Avoid a string of adjectives with no work attached.

Illustrative rewrite: “Technical writer focused on developer documentation. Maintain REST API reference pages and onboarding guides in Markdown, review changes through Git pull requests, and test sample requests against the documented product version.” This describes scope without inventing a business result.

For another role, change the evidence, not just the label: a service-manual writer might describe illustrated procedures and field-engineer review. Claim a regulatory standard only if you worked with its applicable requirements and can explain your contribution. More patterns appear in the professional summary guide.

Replace “responsible for documentation” with the artifact, audience and your contribution. Where relevant, add the product version, review process or publishing responsibility. These details let a reader distinguish drafting, editing, information architecture and tooling work.

A useful sequence is deliverable + audience or scope + method + supported result. The result is optional. These are fictional wording examples, not claims to copy:

• API reference: “Revised authentication and error-response topics for an internal REST API; checked request examples in a test environment and resolved engineer review comments before release.”
• User guide: “Reorganized the administrator guide around setup and permission tasks, with reusable prerequisites and reviewer-approved screenshots.”
• Release notes: “Prepared customer release notes from approved change tickets, confirming affected versions and upgrade instructions with engineering.”
• Knowledge base: “Reviewed help articles against support search queries, merged duplicate topics and recorded owners for future updates.”

If you report a ticket reduction, identify the topic, comparison periods, counting method and other changes that may have affected demand. A before-and-after difference does not establish that documentation alone caused it. Without reliable measurements, describe the verified work. Do not replace an invented percentage with an equally unsupported claim that support staff credited you.

Review and maintenance work can make your contribution clearer. Explain how you gathered information, handled conflicting SME feedback, tested a procedure, recorded approval or updated docs after a product change. A Git workflow bullet should distinguish writing the change from approving or deploying it.

For example: “Submitted documentation pull requests with a version-specific test checklist and incorporated engineering corrections before publication.” This does not imply sole ownership of technical sign-off. Give recent, relevant roles enough space to show distinct work, then compress repetition; bullet-count guidance is a starting point, not a quota.

The following terms describe possible work, not a survey of job postings or a list of guaranteed filters. Choose from the requirements of the role you are applying for, then supply context that shows how you used each relevant term.

Swagger’s OpenAPI overview distinguishes the OpenAPI Specification from the Swagger tools built around it. On a resume, be similarly precise: editing an OpenAPI description, using Swagger UI and writing a conceptual API guide are different activities.

Use recognizable language from the posting where it accurately describes your experience. ATS configurations vary; there is no universal rule that a synonym is ignored or an exact phrase earns an interview. Avoid repeating unsupported skills merely to increase a match score.

For a practical comparison method, see resume keywords. Treat any tool’s gap list as an editing aid and distinguish a wording gap from a skill you have not acquired.

Group tools by what you did with them. Put the groups most relevant to the vacancy first, and omit products you only recognize by name. A readable list could use these categories:

Word can be relevant. Include it when you used it for the work the vacancy requires; it does not by itself signal outdated experience. Describe Git depth honestly. Editing branches and submitting pull requests differs from administering repositories or designing a publishing pipeline. List both structured authoring and docs-as-code when supported. They are not mutually exclusive career tracks.

Separate a markup format, a standard and an application where that distinction helps: Markdown is a markup language, DITA is an XML-based standard for structured content, and an XML editor is a tool. See skills-section examples for ways to connect the list to experience.

If you can share samples, place a readable, clickable portfolio address near your contact details. Choose a few pieces relevant to the role rather than a large unsorted folder. For each, state the audience, purpose, version or date, your contribution, and any limitations on what is shown.

Confidential work: redacting names does not automatically make a document safe to publish. Obtain appropriate permission before sharing employer material or a case study. An independently created guide for a fictional product can demonstrate writing and testing without reusing restricted content. Label it as a personal sample. Observe project licenses and contribution rules when using public projects.

Unbylined public work: link only where appropriate and describe precisely which sections you authored or edited. Do not claim sole authorship of a team document. When samples can only be provided privately, say so accurately and follow the employer’s submission process; a public portfolio is not universally required.

Test links while signed out. Check that the intended sample opens without exposing unrelated files, comments, credentials or private revision history.

Tailor to the vacancy’s deliverables, audience and review responsibilities rather than assuming every software or hardware team uses the same stack. Keep a factual base resume and select relevant evidence for each application. The tailoring guide provides a comparison workflow.

For a developer-facing role, relevant evidence might include API reference, SDK examples, quickstarts or migration guides. Explain whether you tested examples, reviewed source changes, coordinated releases or maintained versioned documentation. For an end-user product role, task guides and support content may be more relevant than API work. A public contribution can help if its scope and your authorship are clear; merely submitting a pull request does not demonstrate every Git skill.

For equipment or manufacturing documentation, relevant work might include installation procedures, service manuals, reusable topics or illustrated parts information. Name the product context, authorized technical reviewers and how you checked instructions against the applicable version. Include standards or compliance responsibilities only when accurate; writing one section does not make you responsible for the product’s overall compliance.

For sensitive roles, follow the application’s approved process for credential or clearance information. Do not infer current authorization from historical employment or disclose restricted project details.

Compare the summary, skills order, leading experience bullets and selected portfolio samples with the vacancy. Keep dates, titles, scope and results consistent across versions. Save a copy before tailoring, then check that the export still opens correctly and that every link leads to the intended sample.