Markdown ble opprettet av John Gruber i 2004 med ett enkelt, elegant mål: skriv ren tekst som leses naturlig, og konverter den deretter til ren HTML. To tiår senere er det overalt — GitHub README-filer, pull request-beskrivelser, Slack-meldinger, Notion-dokumenter, blogginnlegg, AI-chat-svar. Det er ett av de verktøyene du vil bruke hver dag resten av karrieren din, enten du tenker bevisst på det eller ikke.
Hva Markdown faktisk er
Markdown er ren tekst med lett, lesbar syntaks lagt på toppen. Et # i begynnelsen av en linje blir et <h1>. Å pakke inn et ord i **doble asterisker** gjør det fet. Backticks produserer inline kode. Den sentrale designfilosofien er at Markdown-kilde bør være lesbar som den er — selv før den renderes. Hvis du noen gang har skrevet en e-post med *asterisker rundt betoning* eller brukt bindestreker for en punktliste, var du allerede på vei til å skrive noe veldig nært Markdown.
Her er et raskt før-og-etter. Markdown til venstre produserer HTML til høyre:
## Getting Started
Install the package with **npm**:
`npm install my-library`
Then import it in your project — see the [docs](https://example.com) for details.<h2>Getting Started</h2>
<p>Install the package with <strong>npm</strong>:</p>
<p><code>npm install my-library</code></p>
<p>Then import it in your project — see the <a href="https://example.com">docs</a> for details.</p>Du skriver den øverste halvdelen; en Markdown-prosessor produserer den nedre halvdelen. Det oversettelsestrinnet er usynlig når det først er i editoren eller CI-pipelinen din.
Kjernesyntaks — delen alle varianter deler
Uansett hvilken Markdown-variant du bruker, fungerer disse byggesteinene overalt:
- Overskrifter —
# H1,## H2,### H3(opptil seks nivåer) - Fet og kursiv —
**fet**,*kursiv*,***begge*** - Lenker —
[lenketekst](https://url.com) - Bilder —
 - Inline kode —
`backtick`pakker inn et kodestykke; triple backticks åpner en avgrensede kodeblokk - Blokkitater — start en linje med
> - Uordnede lister — linjer som starter med
-eller* - Ordnede lister — linjer som starter med
1.,2., osv. - Horisontal linje — tre eller flere bindestreker:
---
Her er et realistisk README-utdrag som bruker alle ovennevnte sammen:
# json-transform
> A zero-dependency library for transforming JSON structures.
## Installation
```bash
npm install json-transform
```
## Usage
```js
import { transform } from 'json-transform';
const result = transform(input, schema);
```
## Features
- **Fast** — processes 10k objects/sec on average hardware
- *Typed* — ships with full TypeScript definitions
- Zero runtime dependencies
See the [full documentation](https://json-transform.dev/docs) for advanced options.
---
MIT LicenseVariantproblemet — CommonMark, GFM og andre
Her er haken: "Markdown" er ikke én ting. Grubers originale 2004-spesifikasjon var bevisst løs, noe som førte til år med inkompatible implementeringer. Forskjellige parsere håndterte kanttilfeller — nestede lister, tomme linjer inne i blokkitater, prioritet mellom betoning og lenker — på forskjellige måter. Den samme kildefilen ville rendere forskjellig i forskjellige verktøy.
CommonMark (lansert i 2014) fikset dette. En gruppe utviklere — inkludert folk fra GitHub, Stack Overflow og Reddit — skrev en streng, entydig spesifikasjon som dekket hvert kanttilfelle med en testsuite på 652 eksempler. De fleste moderne verktøy bruker nå CommonMark som grunnlinje.
GitHub utvidet deretter CommonMark med sine egne tillegg og publiserte GitHub Flavored Markdown (GFM). GFM er det du skriver i GitHub README-filer, issues og pull requests. Mange andre verktøy har også adoptert GFM-utvidelser, men ikke alle — så det som renderes på GitHub, renderer kanskje ikke på samme måte i den statiske nettstedsgeneratoren eller notis-appen din. Å vite hvilken variant verktøyet ditt støtter sparer mye hodebry.
GitHub Flavored Markdown-utvidelser
GFM legger til fem funksjoner på toppen av CommonMark som du vil bruke konstant på GitHub og ethvert verktøy som støtter GFM-supersettets:
Tabeller — pipe-adskilte kolonner med en separatorrow med bindestreker:
| Method | Returns | Mutates? |
|---------|---------------|----------|
| map() | new array | No |
| filter()| new array | No |
| sort() | same array | Yes |Oppgavelister — avmerkingsbokser i issues og pull requests:
- [x] Write unit tests
- [x] Update CHANGELOG
- [ ] Add migration guide
- [ ] Tag releaseGjennomstrekning — pakk tekst inn i doble tilde:
~~deprecated API~~ — use `newMethod()` insteadAvgrensede kodeblokker med språkantydninger — språkidentifikatoren etter åpningsbegrenseren utløser syntaksmarkering:
```python
def parse_config(path: str) -> dict:
with open(path) as f:
return json.load(f)
```Autolenker — bare URL-er som https://example.com gjøres automatisk klikkbare uten å trenge [tekst](url)-syntaks. Dette er praktisk i issue-kommentarer, men kan være overraskende hvis du limer inn en URL du ikke vil ha lenket.
Hvor du vil bruke Markdown i praksis
Markdown dukker opp på flere steder enn de fleste utviklere forventer når de første gang møter det:
- GitHub og GitLab — README-filer, issues, pull request-beskrivelser, wikier og til og med commit-meldingstekster. Hvert repository du rører, vil ha minst en README.md.
- Statiske nettstedsgeneratorer — Jekyll, Hugo, Eleventy, Astro og Next.js aksepterer alle Markdown-innholdsfiler. Du skriver innlegg i
.md-filer og generatoren konverterer dem til HTML-sider på byggetidspunktet. - Dokumentasjonsverktøy — MkDocs, Docusaurus og GitBook er bygget helt rundt Markdown-kilde. Åpen kildekode-biblioteker bruker nesten universelt ett av disse.
- Notis-apper — Obsidian, Notion, Bear og Typora bruker alle Markdown som sitt native format (med varierende utvidelser). Notatene dine er bærbare ren tekstfiler, ikke en proprietær database.
- CMS-plattformer — Ghost bruker Markdown innebygd. Contentful og Strapi støtter begge Markdown-felt. Headless CMS-oppsett lagrer typisk langforminnhold som Markdown-strenger.
- AI-verktøy — ChatGPT og Claude sender begge ut Markdown som standard. Kodestykker, fete termer og punktlister i AI-svar er Markdown — chat-UI-et renderer dem, men den underliggende teksten er
**fet**og```python.
Markdown vs HTML — når bruker man hva
Markdown konverteres til HTML, men det kan ikke uttrykke alt HTML kan. Det er ingen ekvivalent for <div class="card">, data-*-attributter eller aria-*-attributter. For enkelt proseinnhold — dokumentasjon, README-filer, blogginnlegg, endringslogger — er Markdown raskere å skrive og langt mer lesbar i sin råe form. For komplekse UI-komponenter, egendefinerte oppsett eller tilgjengelighetsnoteringer som krever spesifikke attributter, trenger du HTML.
Den gode nyheten: de fleste Markdown-prosessorer tillater rå HTML inline. Du kan blande de to. Hvis du trenger en <figure> med en <figcaption>, eller en <details>-avsløringsgadget, skriv bare HTML direkte i .md-filen din. Prosessoren lar det passere urørt. Bruk denne rømningsluken sparsomt — hvis mer enn en tredjedel av filen din er rå HTML, kan du like gjerne skrive HTML direkte og bruke vårt HTML-formateringsverktøy for å holde det rent.
- Bruk Markdown for: dokumentasjon, README-filer, endringslogger, blogginnlegg, kunnskapsbase-artikler, API-beskrivelsesfelt
- Bruk HTML for: presist oppsett, egendefinerte komponenter, skjemaer, elementer som krever spesifikke attributter
- Bland begge når: mesteparten av proseinnhold med en håndfull strukturelle unntak (en responsiv tabell, en videoinnbygging)
Oppsummering
Markdown er bedragelig enkelt — det ser ut som bare en håndfull tegnsettingsregler, men det driver dokumentasjon for nesten alle store åpen kildekode-prosjekter. Å forstå kjernesyntaksen tar omtrent ti minutter. Å forstå variantforskjellene (CommonMark vs GFM vs hva SSG-en din bruker) er det som skiller utviklere som av og til kjemper med dokumentasjonsverktøykjeden fra de som ikke gjør det.
De autoritative referansene: CommonMark for den standardiserte spesifikasjonen, GitHub Flavored Markdown for GitHub-utvidelsene og Markdown Guide for en praktisk jukselapp-referanse. For daglig skriving lar vårt Markdown-forhåndsvisning-verktøy deg se rendert utdata umiddelbart, og Markdown-formateringsverktøyet holder kildefilene dine konsistente.