📝Developer

How to Write a README That People Actually Read

Most READMEs are either too long or missing critical information. Here's the structure that works for open-source libraries, internal tools, and side projects.

5 min readFebruary 26, 2026By FreeToolKit TeamFree to read

Open GitHub on any given day and you'll find repositories with a single line README ('a fast JSON formatter') and no installation instructions. You'll also find 50-page READMEs that bury the installation command under 2,000 words of motivation. Neither is useful. Here's the structure that actually works.

The One-Sentence Description

First line of the README: what it does in one sentence. Not 'FastJSON is a modern, blazingly fast JSON formatter built for developers who need performance and reliability.' Just 'Format and validate JSON in under 1ms. Works in Node.js and the browser.' Specificity beats marketing language every time.

The Section Order That Works

  1. 1One-line description + key benefit
  2. 2Installation (exact commands, copy-paste ready)
  3. 3Quick start example (the smallest working example)
  4. 4Common use cases with code
  5. 5Configuration reference
  6. 6API reference (or link to it)
  7. 7Contributing guidelines
  8. 8License

The Installation Section

Never say 'install the package using your preferred package manager.' Say 'npm install fast-json — or yarn add fast-json if you use Yarn.' Assume nothing and be complete. Include the import statement immediately after installation so the reader's first code works without hunting for it.

Code Examples: The Critical Section

Every example should run without modification. No placeholder values that require substitution unless you clearly mark them. No 'see documentation for details' when the detail is a parameter type. The reader's first experience with your project is running the quick start example — if it fails because of missing information, you've lost them.

Markdown Format Choices

Use fenced code blocks with language identifiers (```javascript instead of just ```) — GitHub applies syntax highlighting and makes copy buttons appear. Use a table for configuration options rather than a bullet list — much more scannable. Use collapsible sections (<details><summary>) for long sections that most readers can skip.

Test your README

Ask someone unfamiliar with the project to get it running using only the README. Where they get stuck, the README has a gap. This is a more useful test than reading it yourself — you know all the missing context and fill it in automatically.

Frequently Asked Questions

What should always be in a README?+
The absolute minimum: what the project does in one sentence, how to install it, and one working example. Everything else is helpful context. Many developers spend time on extensive features sections while omitting 'npm install' instructions, which is the one thing every new user needs. Prioritize the onboarding path over the feature list.
How long should a README be?+
Long enough to answer the most common questions, short enough to scan in 3 minutes. For a utility library: what it does, installation, the 3 most common use cases with code, and a link to full documentation. For a full application: add architecture overview and development setup. Readmes that are 10,000 words mostly get skimmed or skipped — put detailed documentation in a /docs folder or wiki instead.
Should I add badges to my README?+
Badges (CI status, coverage, version, license) serve a real purpose for open-source projects: they communicate project health at a glance. A green CI badge tells maintainers the main branch is passing. A version badge tells users if they're looking at the latest docs. But badge collections that extend 8 rows into the README before any meaningful content are noise. Keep it to 3–5 relevant badges maximum.
What's the difference between a README and documentation?+
The README is the front door — it answers 'what is this and how do I start.' Documentation is the full reference — it covers every function, configuration option, and edge case. The README should link to documentation for depth. Trying to put everything in the README produces a document too long to read and too disorganized to reference.

🔧 Free Tools Used in This Guide

FT

FreeToolKit Team

FreeToolKit Team

We build free browser-based tools and write practical guides that skip the fluff.

Tags:

developerdocumentationmarkdowngithub