Dies ist die Markdown-Syntaxreferenz, die man als Lesezeichen speichern und immer wieder aufrufen kann. Jedes Element wird mit einem echten Beispiel behandelt — Überschriften, Betonung, Links, Bilder, Listen, Codeblöcke, Tabellen, Blockzitate und mehr. Wo eine Funktion Teil des Standard-CommonMark ist, wird es entsprechend gekennzeichnet; Erweiterungen von GitHub Flavored Markdown (GFM) werden explizit ausgewiesen, damit man weiß, was universell unterstützt wird und was vom Renderer abhängt.
Überschriften
Markdown hat zwei Überschriftenstile. Der ATX-Stil verwendet Raute-Zeichen — ein # für h1 bis sechs ###### für h6. Der Setext-Stil verwendet Unterstreichungen aus =- oder --Zeichen und erreicht nur h1 und h2. ATX ist der Stil, den man überall verwenden sollte — er ist explizit, skaliert auf alle sechs Ebenen und wird von jedem Tool unterstützt. Ein häufiger Fehler: das Leerzeichen nach dem # zu vergessen. Streng genommen ist #Überschrift in CommonMark keine Überschrift — das Leerzeichen ist erforderlich.
# 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 einem echten Dokument verwendet man typischerweise ein h1 oben (den Dokumenttitel), h2 für Hauptabschnitte und h3 für Unterabschnitte darin. Tiefer als h3 zu gehen ist ein Signal, dass das Dokument möglicherweise umstrukturiert werden muss, anstatt eine weitere Verschachtelungsebene hinzuzufügen.
# lassen. #Überschrift wird von vielen strikten Parsern stillschweigend als Absatz behandelt. Die CommonMark-Spezifikation erfordert mindestens ein Leerzeichen zwischen den #-Zeichen und dem Überschriftentext.Textformatierung
Fett verwendet doppelte Sternchen oder doppelte Unterstriche. Kursiv verwendet einzelne Sternchen oder einzelne Unterstriche. Fett-Kursiv kombiniert drei von einem. Durchgestrichen ist eine GFM-Erweiterung und verwendet doppelte Tilden. Inline-Code verwendet Backticks.
**Bold text** or __Bold text__
*Italic text* or _Italic text_
***Bold and italic*** or ___Bold and italic___
~~Strikethrough~~ (GFM only)
`inline code`Die *- und _-Varianten sind größtenteils austauschbar, unterscheiden sich aber in einem Grenzfall: Betonung mitten im Wort. Sternchen funktionieren mitten im Wort (un*glaub*lich wird als unglaublich gerendert), aber Unterstriche nicht — un_glaub_lich wird in CommonMark buchstäblich gerendert, weil Unterstriche in Wörtern als Wortzeichen und nicht als Betonungsmarkierungen behandelt werden. Das ist wichtig in technischem Schreiben, wo Unterstriche in Bezeichnern erscheinen. Als Regel: * für Betonung verwenden und _ nur reservieren, wenn man eine starke Stilpräferenz hat. Nicht * und _ innerhalb derselben Betonungsspanne mischen — *text_ wird nicht korrekt geschlossen.
Links und Bilder
Es gibt drei Linkstile: Inline-Links, Referenzlinks und Autolinks. Bilder folgen derselben Syntax wie Inline-Links, aber mit einem !-Präfix.
<!-- 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- oder height-Attribute. Die -Syntax wird auf ein einfaches <img>-Tag ohne Größenangabe abgebildet. Wenn man Bildabmessungen steuern muss, muss man auf rohes HTML zurückgreifen: <img src="url" alt="text" width="400">. Dies ist eine bekannte Einschränkung — der Markdown Guide deckt die Problemumgehung ab.Listen
Ungeordnete Listen verwenden -, * oder + als Aufzählungszeichen. Geordnete Listen verwenden Zahlen gefolgt von einem Punkt. Listen durch Einrücken um zwei oder vier Leerzeichen verschachteln. Aufgabenlisten (GFM) verwenden [ ] für nicht angehakt und [x] für angehakt.
<!-- 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 und umzäunt
Inline-Code verwendet auf jeder Seite einen einzelnen Backtick. Für Blöcke dreifache Backticks (umzäunte Codeblöcke) verwenden und optional den Sprachbezeichner direkt nach dem öffnenden Zaun angeben — dies aktiviert Syntaxhervorhebung in GitHub, VS Code-Vorschauen und den meisten statischen Site-Generatoren. Man kann auch eingerückte Codeblöcke verwenden (4 Leerzeichen Einrückung), aber umzäunte Blöcke bevorzugen: Sie unterstützen Sprachhinweise, sind explizit und funktionieren sogar, wenn der umgebende Inhalt auch Einrückungen hat.
<!-- 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
```Häufige Sprachbezeichner: python, js oder javascript, ts oder typescript, bash oder sh, json, yaml, html, css, sql, go, rust, java. Mit dem Markdown-Vorschau-Tool anschauen, wie das Markdown gerendert wird.
Tabellen (GFM)
Tabellen sind eine GitHub Flavored Markdown-Erweiterung — sie sind nicht Teil des CommonMark-Standards. Sie funktionieren in GitHub, GitLab, den meisten statischen Site-Generatoren und VS Code, aber nicht in allen Markdown-Prozessoren. Die Syntax verwendet Pipe-Zeichen, um Spalten zu trennen, und eine Trennzeile aus Bindestrichen, um den Header zu markieren. Doppelpunkte in der Trennzeile steuern die Spaltenausrichtung.
| Feature | CommonMark | GFM |
| -------------------- | :--------: | :-------: |
| Headings | ✅ | ✅ |
| Bold / Italic | ✅ | ✅ |
| Fenced code blocks | ✅ | ✅ |
| Tables | ❌ | ✅ |
| Task lists | ❌ | ✅ |
| Strikethrough | ❌ | ✅ |
| Autolinks | ✅ | ✅ (ext.) |Die Spaltenausrichtung wird in der Trennzeile festgelegt. :--- richtet links aus (Standard). ---: richtet rechts aus. :---: zentriert. Man muss Spalten im Quelltext nicht mit Leerzeichen auffüllen, um sie visuell auszurichten — das ist kosmetisch und hat keinen Einfluss auf die gerenderte Ausgabe. Die Pipes am Anfang und Ende jeder Zeile sind in GFM technisch optional, aber sie einzuschließen ist der übersichtlichere Stil.
Blockzitate
Blockzitate setzen jeder Zeile ein > voran. Verschachtelte Blockzitate verwenden >>. Man kann andere Markdown-Elemente — Überschriften, Listen, Codeblöcke — in einem Blockzitat einfügen, was sie für Hinweis-Boxen in der Dokumentation nützlich macht.
> **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 Linien, Zeilenumbrüche und Escaping
Diese drei Funktionen bringen Menschen durcheinander, weil ihr Verhalten wie ein Fehler aussieht, bis man die Regeln kennt. Horizontale Linien, harte Zeilenumbrüche und Backslash-Escaping haben alle eine spezifische Syntax, die nicht offensichtlich ist.
<!-- 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 -->
\ ` * _ { } [ ] ( ) # + - . !\)-Ansatz ist robuster, wenn der Editor oder die CI-Pipeline abschließende Leerzeichen entfernt. Alternativ den Inhalt umstrukturieren, damit weniger harte Zeilenumbrüche benötigt werden — diese sind am häufigsten in Gedichten oder Adressen notwendig, nicht in der Dokumentation.HTML in Markdown
Die meisten Markdown-Prozessoren geben rohes HTML unverändert weiter, was eine Handvoll nützlicher Muster freischaltet, die die reine Markdown-Syntax nicht ausdrücken kann. Der häufigste Anwendungsfall in GitHub-READMEs ist der aufklappbare <details>/<summary>-Abschnitt. Andere nützliche: <kbd> für Tastaturkürzel und benutzerdefinierte id-Attribute auf Überschriften für präzise 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).Ein wichtiger Vorbehalt: Der <details>-Block erfordert eine Leerzeile zwischen dem schließenden </summary>-Tag und dem Hauptinhalt, wenn dieser Inhalt Markdown enthält. Ohne die Leerzeile wird das Markdown darin nicht geparst — es wird als Rohtext gerendert. Mit dem Markdown Formatter-Tool können die Markdown-Dateien bereinigt und formatiert werden.
Zusammenfassung
Das deckt die vollständige Syntax ab — Standard-CommonMark und die GFM-Erweiterungen, die Entwickler täglich verwenden. Für das autoritäre Wort zu Grenzfällen sind die CommonMark-Spezifikation und die GFM-Spezifikation beide lesbare Dokumente, keine bloßen Referenz-Dumps. Die CommonMark-Kurzreferenz ist eine handliche einseitige Zusammenfassung. Die Markdown Guide Grundlegende Syntax und die Seiten zur erweiterten Syntax sind ebenfalls gut organisiert, wenn man mehr Prosaerklärung neben Beispielen möchte. Wenn man genau sehen möchte, wie das Markdown aussehen wird, bevor man es committet, rendert das Markdown-Vorschau-Tool es live im Browser. Um inkonsistente Formatierung in einem Dokument zu bereinigen, normalisiert der Markdown Formatter Überschriftenstile, Listenmarkierungen und Abstände. Und für sauberes HTML aus Markdown-Ausgabe formatiert der HTML Formatter alles, was der Markdown-Prozessor ausgibt.