Dit is de Markdown-syntaxisreferentie die je kunt bookmarken en later kunt terugkeren. Elk element gedekt met een echt voorbeeld — koppen, nadruk, links, afbeeldingen, lijsten, codeblokken, tabellen, blokcitaten en meer. Waar een functie deel uitmaakt van standaard CommonMark is dat als zodanig aangegeven; extensies van GitHub Flavored Markdown (GFM) worden expliciet vermeld zodat je weet wat universeel wordt ondersteund en wat afhangt van de renderer.
Koppen
Markdown heeft twee kopstijlen. De ATX-stijl gebruikt hekjes — één # voor h1 tot zes ###### voor h6. De setext-stijl gebruikt onderstrepingen van =- of --tekens en bereikt alleen h1 en h2. ATX is de stijl die je overal moet gebruiken — het is expliciet, het schaalt naar alle zes niveaus, en het wordt door elk gereedschap ondersteund. Een veelgemaakte fout: de spatie na het # vergeten. Strikt genomen is #Kop geen kop in CommonMark — de spatie is verplicht.
# Page Title (h1)
## Section Heading (h2)
### Subsection (h3)
#### Detail Level (h4)
##### Minor Heading (h5)
###### Smallest Heading (h6)
---
<!-- Setext style — only h1 and h2, rarely used -->
Page Title
==========
Section Heading
---------------In een echt document gebruik je doorgaans één h1 bovenaan (de documenttitel), h2 voor hoofdsecties en h3 voor subsecties daarbinnen. Dieper gaan dan h3 is een signaal dat je document misschien herstructurering nodig heeft in plaats van een ander nestingniveau.
#. #Kop wordt door veel strikte parsers stilzwijgend als een alinea behandeld. De CommonMark-specificatie vereist minimaal één spatie tussen de #-tekens en de koptekst.Tekstopmaak
Vet gebruikt dubbele asterisken of dubbele underscores. Cursief gebruikt enkele asterisken of enkele underscores. Vet-cursief combineert drie van beide. Doorgestreept is een GFM-extensie en gebruikt dubbele tildes. Inline code gebruikt backticks.
**Bold text** or __Bold text__
*Italic text* or _Italic text_
***Bold and italic*** or ___Bold and italic___
~~Strikethrough~~ (GFM only)
`inline code`De *- en _-varianten zijn grotendeels uitwisselbaar, maar ze verschillen in één randgeval: middenwoordnadruk. Asterisken werken midden in een woord (on*ge*looflijk wordt gerenderd als ongelooflijk), maar underscores niet — on_ge_looflijk wordt letterlijk gerenderd in CommonMark omdat underscores binnen woorden als woordtekens worden behandeld, niet als nadrukmarkeringen. Dit is belangrijk in technisch schrijven waar underscores in identifiers verschijnen. Als vuistregel: gebruik * voor nadruk en reserveer _ alleen als je een sterke stijlvoorkeur hebt. Meng * en _ niet binnen hetzelfde nadrukbereik — *tekst_ zal niet correct sluiten.
Links en Afbeeldingen
Er zijn drie linkstijlen: inline links, referentielinks en autolinks. Afbeeldingen volgen dezelfde syntaxis als inline links maar met een !-voorvoegsel.
<!-- Inline link: [text](url) or [text](url "title") -->
Read the [CommonMark spec](https://spec.commonmark.org/current/ "CommonMark Specification")
Format Markdown with the [Markdown Formatter](/markdown-formatter)
<!-- Reference link: define the URL separately — cleaner in long documents -->
Check the [GFM spec][gfm] for GitHub-specific extensions.
[gfm]: https://github.github.com/gfm/
<!-- Autolink: angle brackets make a URL or email clickable -->
<https://commonmark.org>
<[email protected]>
<!-- Image: same as inline link but with ! prefix -->

width- of height-attributen. De syntaxis  mapt naar een eenvoudige <img>-tag zonder maatvoering. Als je afbeeldingsafmetingen moet beheren, moet je overstappen naar ruwe HTML: <img src="url" alt="tekst" width="400">. Dit is een bekende beperking — de Markdown Guide behandelt de oplossing.Lijsten
Ongeordende lijsten gebruiken -, * of + als opsommingstekens. Geordende lijsten gebruiken nummers gevolgd door een punt. Nest lijsten door twee of vier spaties in te springen. Takenlijsten (GFM) gebruiken [ ] voor niet-aangevinkte en [x] voor aangevinkte items.
<!-- Unordered list -->
- Install dependencies
- Configure environment variables
- Run the dev server
<!-- Ordered list -->
1. Clone the repository
2. Run `npm install`
3. Copy `.env.example` to `.env` and fill in values
4. Run `npm run dev`
<!-- Nested list (indent 2 or 4 spaces) -->
- Backend
- Set up PostgreSQL
- Configure connection string
- Frontend
- Install Tailwind
- Configure PostCSS
<!-- Task list (GFM) — great for README checklists -->
## Release Checklist
- [x] Unit tests passing
- [x] End-to-end tests passing
- [ ] Changelog updated
- [ ] Docker image tagged
- [ ] Deployment approvedCode — Inline en Omheind
Inline code gebruikt een enkele backtick aan elke kant. Voor blokken, gebruik drievoudige backticks (omheinde codeblokken) en specificeer optioneel de taalidentificator direct na de openende omheining — dit schakelt syntaxismarkering in bij GitHub, VS Code-voorbeelden en de meeste statische sitegenerators. Je kunt ook ingesprongen codeblokken gebruiken (4 spaties inspringing), maar geef de voorkeur aan omheinde blokken: ze ondersteunen taalhinten, zijn expliciet en werken zelfs wanneer de omliggende inhoud ook inspringing heeft.
<!-- Inline code -->
Use the `fetch()` API to make HTTP requests.
Set the `Content-Type` header to `application/json`.
<!-- Fenced code block with language hint -->
```python
import json
with open("config.json") as f:
config = json.load(f)
print(config["database"]["host"])
```
```typescript
interface ApiResponse<T> {
data: T;
status: number;
message: string;
}
async function fetchUser(id: string): Promise<ApiResponse<User>> {
const res = await fetch(`/api/users/${id}`);
return res.json();
}
```
```bash
# Install dependencies and start the dev server
npm install
npm run dev
```
```json
{
"name": "my-project",
"version": "1.0.0",
"scripts": {
"dev": "vite",
"build": "tsc && vite build"
}
}
```
```yaml
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
```Veelgebruikte taalidentificatoren: python, js of javascript, ts of typescript, bash of sh, json, yaml, html, css, sql, go, rust, java. Bekijk hoe je Markdown wordt gerenderd met de Markdown Preview-tool.
Tabellen (GFM)
Tabellen zijn een GitHub Flavored Markdown-extensie — ze maken geen deel uit van de CommonMark-standaard. Ze werken in GitHub, GitLab, de meeste statische sitegenerators en VS Code, maar niet in alle Markdown-processors. De syntaxis gebruikt pipe-tekens om kolommen te scheiden en een scheidingsrij van koppeltekens om de koptekst te markeren. Dubbele punten in de scheidingsrij regelen de uitlijning van kolommen.
| Feature | CommonMark | GFM |
| -------------------- | :--------: | :-------: |
| Headings | ✅ | ✅ |
| Bold / Italic | ✅ | ✅ |
| Fenced code blocks | ✅ | ✅ |
| Tables | ❌ | ✅ |
| Task lists | ❌ | ✅ |
| Strikethrough | ❌ | ✅ |
| Autolinks | ✅ | ✅ (ext.) |Kolomuitlijning wordt ingesteld in de scheidingsrij. :--- lijnt links uit (de standaard). ---: lijnt rechts uit. :---: centreert. Je hoeft kolommen niet met spaties te vullen om ze visueel uitgelijnd te maken in de bron — dat is cosmetisch en heeft geen invloed op de gerenderde uitvoer. De pipes aan het begin en einde van elke rij zijn technisch optioneel in GFM, maar ze opnemen is de duidelijkere stijl.
Blokcitaten
Blokcitaten plaatsen > voor elke regel. Geneste blokcitaten gebruiken >>. Je kunt andere Markdown-elementen — koppen, lijsten, codeblokken — opnemen in een blokcitaat, waardoor ze nuttig zijn voor uitroepvakken in documentatie.
> **Note:** As of Node.js 18, the `fetch` API is available globally
> without importing anything. No more `node-fetch` dependency.
> This is a quote that spans
> multiple lines.
>
> And has a second paragraph.
> Outer quote.
>
> > Nested quote — useful for "quoting a quote" in changelogs
> > or spec discussions.
<!-- Blockquote containing a code block — useful for quoting error messages -->
> The migration failed with:
>
> ```
> ERROR: relation "users" already exists
> ```Horizontale Lijnen, Regelafbrekingen en Escaping
Deze drie functies struikelen mensen omdat hun gedrag eruitziet als een bug totdat je de regels kent. Horizontale lijnen, harde regelafbrekingen en backslash-escaping hebben allemaal specifieke syntaxis die niet voor de hand liggend is.
<!-- Horizontal rules: three or more of ---, ***, or ___ on their own line -->
---
***
___
<!-- All three render as <hr>. Most common style is --- -->
<!-- Hard line breaks: end a line with two trailing spaces, or use backslash -->
First line with two trailing spaces
Second line (rendered as a new line, not a new paragraph)
First line with backslash\
Second line (same result)
<!-- A single newline in Markdown source is NOT a line break — it's a space.
Two newlines = a paragraph break. -->
<!-- Backslash escaping: put before any Markdown character to render it literally -->
*This is not italic*
# This is not a heading
[Not a link](not-a-url)
`Not inline code`
<!-- Characters that can be escaped -->
\ ` * _ { } [ ] ( ) # + - . !\) is robuuster als je editor of CI-pipeline afsluitende spaties verwijdert. Herstructureer anders je inhoud zodat je minder harde regelafbrekingen nodig hebt — ze zijn het meest nodig in poëzie of adressen, niet in documentatie.HTML in Markdown
De meeste Markdown-processors geven ruwe HTML ongewijzigd door, waardoor een handvol nuttige patronen worden ontgrendeld die de pure Markdown-syntaxis niet kan uitdrukken. Het meest gebruikte geval in GitHub README's is de inklapbare sectie <details>/<summary>. Andere nuttige: <kbd> voor sneltoetsen en aangepaste id-attributen op koppen voor precieze ankerkoppelingen.
<!-- Collapsible section — very common in GitHub READMEs -->
<details>
<summary>Click to expand: Advanced configuration options</summary>
You can override the defaults by creating a `config.local.json` file
in the project root. Supported keys:
| Key | Default | Description |
| ---------- | ------- | ----------------------- |
| `port` | 3000 | Dev server port |
| `logLevel` | `info` | One of debug/info/warn |
</details>
<!-- Keyboard shortcuts -->
Press <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> to open the command palette.
<!-- Custom heading ID for anchor links -->
<h2 id="configuration-reference">Configuration Reference</h2>
<!-- Link to that heading from anywhere -->
See the [Configuration Reference](#configuration-reference).Één belangrijke waarschuwing: het <details>-blok vereist een lege regel tussen de sluitende tag </summary> en de body-inhoud als die body-inhoud Markdown bevat. Zonder de lege regel wordt de Markdown erin niet geparseerd — het wordt weergegeven als ruwe tekst. Je kunt je Markdown-bestanden opschonen en opmaken met de Markdown Formatter-tool.
Afsluiting
Dat dekt de volledige syntaxis — standaard CommonMark en de GFM-extensies die ontwikkelaars dagelijks gebruiken. Voor het gezaghebbende woord over randgevallen zijn de CommonMark-specificatie en de GFM-specificatie beide leesbare documenten, geen pure referentiedumps. De CommonMark-snelle referentie is een handige samenvatting op één pagina. De pagina's basissyntaxis en uitgebreide syntaxis van de Markdown Guide zijn ook goed georganiseerd als je naast voorbeelden meer proza-uitleg wilt. Wanneer je precies wilt zien hoe je Markdown eruit zal zien voordat je commit, rendert de Markdown Preview-tool het live in je browser. Om inconsistente opmaak in een document op te schonen, normaliseert de Markdown Formatter kopstijlen, lijstmarkeringen en spatiëring. En voor het produceren van schone HTML uit Markdown-uitvoer, maakt de HTML Formatter alles mooi wat de Markdown-processor uitgeeft.