Dette er Markdown-syntaksreferencen, du kan bogmærke og vende tilbage til. Hvert element dækket med et reelt eksempel — overskrifter, betoning, links, billeder, lister, kodeblokke, tabeller, blokcitater og mere. Hvor en funktion er en del af standard CommonMark, er den markeret som sådan; udvidelser fra GitHub Flavored Markdown (GFM) er nævnt eksplicit, så du ved, hvad der er universelt understøttet, og hvad der afhænger af rendereren.
Overskrifter
Markdown har to overskriftsstile. ATX-stilen bruger hash-tegn — ét # for h1 til seks ###### for h6. Setext-stilen bruger understregninger af =- eller --tegn og rækker kun til h1 og h2. ATX er den stil, du bør bruge overalt — den er eksplicit, skalerer til alle seks niveauer, og det er den, hvert værktøj understøtter. En almindelig fejl: at glemme mellemrummet efter #. Strengt taget er #Overskrift ikke en overskrift i CommonMark — mellemrummet er påkrævet.
# 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
---------------I et rigtigt dokument bruger du typisk ét h1 øverst (dokumenttitlen), h2 til større afsnit og h3 til underafsnit inden for disse. At gå dybere end h3 er et signal om, at dit dokument måske har brug for omstrukturering snarere end endnu et niveau af nesting.
#. #Overskrift behandles stille som et afsnit af mange strenge parsere. CommonMark-specifikationen kræver mindst ét mellemrum mellem #-tegnene og overskriftsteksten.Tekstformatering
Fed bruger dobbelte asterisker eller dobbelte underscores. Kursiv bruger enkle asterisker eller enkle underscores. Fed-kursiv kombinerer tre af enten. Gennemstregning er en GFM-udvidelse og bruger dobbelte tildetegn. Inline kode bruger backticks.
**Bold text** or __Bold text__
*Italic text* or _Italic text_
***Bold and italic*** or ___Bold and italic___
~~Strikethrough~~ (GFM only)
`inline code`*- og _-varianterne er for det meste udskiftelige, men de adskiller sig i ét kanttilfælde: betoning midt i ord. Asterisker virker midt i ord (un*believe*able renderes som unbelieveable), men underscores gør det ikke — un_believe_able renderes bogstaveligt i CommonMark, fordi underscores inde i ord behandles som ordtegn, ikke betoningsmarkører. Dette betyder noget i teknisk skrivning, hvor underscores forekommer i identifikatorer. Som en tommelfingerregel: brug * til betoning og reservér _ kun hvis du har en stærk stilpræference. Bland ikke * og _ inden for det samme betoningsspænd — *tekst_ lukkes ikke korrekt.
Links og billeder
Der er tre linkstile: inline links, referencellinks og autolinks. Billeder følger den samme syntaks som inline links, men med et !-præfiks.
<!-- 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- eller height-attributter. Syntaksen  mapper til et simpelt <img>-tag uden størrelsesangivelse. Hvis du har brug for at kontrollere billeddimensioner, skal du falde ned i rå HTML: <img src="url" alt="tekst" width="400">. Dette er en kendt begrænsning — Markdown Guide dækker løsningen.Lister
Usorterede lister bruger -, * eller + som punktmarkører. Sorterede lister bruger tal efterfulgt af et punktum. Nest lister ved at indrykke to eller fire mellemrum. Opgavelister (GFM) bruger [ ] til ikke-afkrydset og [x] til afkrydset elementer.
<!-- 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 approvedKode — inline og afgrænset
Inline kode bruger en enkelt backtick på hver side. Til blokke bruger du triple backticks (afgrænsede kodeblokke) og angiver eventuelt sprogidentifikatoren lige efter den åbnende afgrænsning — dette aktiverer syntaksfremhævning på GitHub, VS Code-forhåndsvisninger og de fleste statiske webstedsgeneratorer. Du kan også bruge indrykkede kodeblokke (4 mellemrums indrykke), men foretræk afgrænsede blokke: de understøtter sprogantydninger, de er eksplicitte og de virker selv når det omgivende indhold også har indrykke.
<!-- 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
```Almindelige sprogidentifikatorer: python, js eller javascript, ts eller typescript, bash eller sh, json, yaml, html, css, sql, go, rust, java. Forhåndsvis, hvordan din Markdown renderes, med Markdown-forhåndsvisning-værktøjet.
Tabeller (GFM)
Tabeller er en GitHub Flavored Markdown-udvidelse — de er ikke en del af CommonMark-standarden. De virker på GitHub, GitLab, de fleste statiske webstedsgeneratorer og VS Code, men ikke i alle Markdown-processorer. Syntaksen bruger pipe-tegn til at adskille kolonner og en separatorrække af bindestreger til at markere overskriften. Koloner i separatorrækken styrer kolonnejustering.
| Feature | CommonMark | GFM |
| -------------------- | :--------: | :-------: |
| Headings | ✅ | ✅ |
| Bold / Italic | ✅ | ✅ |
| Fenced code blocks | ✅ | ✅ |
| Tables | ❌ | ✅ |
| Task lists | ❌ | ✅ |
| Strikethrough | ❌ | ✅ |
| Autolinks | ✅ | ✅ (ext.) |Kolonnejustering angives i separatorrækken. :--- justerer venstre (standard). ---: justerer højre. :---: centrerer. Du behøver ikke at polstre kolonner med mellemrum for at gøre dem visuelt justerede i kilden — det er kosmetisk og har ingen effekt på det renderede output. Pipe-tegnene i starten og slutningen af hver række er teknisk set valgfrie i GFM, men at inkludere dem er den tydeligere stil.
Blokcitater
Blokcitater prefixer hver linje med >. Nestede blokcitater bruger >>. Du kan inkludere andre Markdown-elementer — overskrifter, lister, kodeblokke — inde i et blokcitat, hvilket gør dem nyttige til callout-bokse i dokumentation.
> **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
> ```Vandrette linjer, linjeskift og escaping
Disse tre funktioner snubler folk over, fordi deres adfærd ligner en fejl, indtil du kender reglerne. Vandrette linjer, hårde linjeskift og backslash-escaping har alle specifik syntaks, der ikke er åbenlys.
<!-- 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 -->
\ ` * _ { } [ ] ( ) # + - . !\)-tilgangen er mere robust, hvis din editor eller CI-pipeline fjerner efterfølgende mellemrum. Alternativt kan du omstrukturere dit indhold, så du har brug for færre hårde linjeskift — de er oftest nødvendige i poesi eller adresser, ikke i dokumentation.HTML i Markdown
De fleste Markdown-processorer lader rå HTML passere uændret, hvilket låser op for en håndfuld nyttige mønstre, som ren Markdown-syntaks ikke kan udtrykke. Den mest almindelige brugscase i GitHub README-filer er det sammenklappelige <details>/<summary>-afsnit. Andre nyttige: <kbd> til tastaturgenveje og brugerdefinerede id-attributter på overskrifter til præcise ankerlinks.
<!-- 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).En vigtig advarsel: <details>-blokken kræver en tom linje mellem det afsluttende </summary>-tag og brødtekstindholdet, hvis dette indhold indeholder Markdown. Uden den tomme linje vil Markdown inde i blokken ikke blive parset — det renderes som rå tekst. Du kan rydde op i og formatere dine Markdown-filer med Markdown-formateringsværktøjet.
Opsummering
Det dækker den fulde syntaks — standard CommonMark og de GFM-udvidelser, udviklere bruger dagligt. For det autoritative ord om kanttilfælde er CommonMark-specifikationen og GFM-specifikationen begge læsbare dokumenter, ikke blot referencedumps. CommonMark-hurtigreferencen er en praktisk enkeltsidesopsummering. Markdown Guide grundlæggende syntaks og udvidet syntaks-siderne er også velorganiserede, hvis du vil have mere prosaforklaring ved siden af eksempler. Når du har brug for at se præcis, hvordan din Markdown vil se ud inden du committer, renderes den live i din browser med Markdown-forhåndsvisning-værktøjet. For at rydde op i inkonsekvent formatering på tværs af et dokument normaliserer Markdown-formateringsværktøjet overskriftsstile, listemarkører og afstand. Og til at producere rent HTML fra Markdown-output forskønnerer HTML-formateringsværktøjet det, Markdown-processoren udsender.