A Nostr event has three moving parts: its kind (what type of thing it is), its content (the payload), and its tags (structured metadata that links events together and tells clients how to handle them). We already publish a NIPs reference for the specification documents and an event-kinds registry for the kind-number namespace. This page fills the third leg: the standardized tags — the small, reusable labels that appear inside nearly every event.
Each tag is a JSON array whose first element is the tag name. Single-letter tags (e, p, a, t…) are special: relays index them, so they are the ones you can efficiently filter and query on. Every definition below is quoted from its defining NIP in the canonical nostr-protocol/nips repository; where a tag’s meaning is refined across several NIPs, the most relevant one is cited.
Core reference tags (NIP-01)
These three are defined in the base protocol and mean the same thing across every event kind. The d tag joins them as the identifier for addressable events.
| Tag | Purpose | Structure | NIP |
|---|---|---|---|
e |
Reference another event | ["e", <event-id hex>, <relay URL, optional>, <author pubkey, optional>] |
NIP-01 |
p |
Reference another user | ["p", <pubkey hex>, <relay URL, optional>] |
NIP-01 |
a |
Reference an addressable/replaceable event by coordinate | ["a", "<kind>:<pubkey>:<d-tag value>", <relay URL, optional>] |
NIP-01 |
d |
Identifier that makes an addressable event unique per author+kind | ["d", <identifier string>] |
NIP-01 |
Threading, quoting & reactions
| Tag | Purpose | Structure | NIP |
|---|---|---|---|
e (marked) |
Thread structure: a marker distinguishes the root from a direct reply | ["e", <event-id>, <relay-url>, <marker>, <pubkey>] where marker is "root" or "reply" |
NIP-10 |
q |
Quote-repost another event (embeds it rather than replying) | ["q", "<event-id or address>", "<relay-url>", "<pubkey>"] |
NIP-18 |
k |
The stringified kind number of a referenced/reacted event | ["k", "<kind integer as string>"] |
NIP-25, NIP-72 |
For reactions (kind 7), NIP-25 requires an e tag (the event reacted to) and recommends a p tag (its author); the reaction event MAY add a k tag carrying the reacted event’s kind.
Discovery & references
| Tag | Purpose | Structure | NIP |
|---|---|---|---|
t |
Hashtag — the value MUST be a lowercase string | ["t", <lowercase hashtag>] |
NIP-24 |
r |
A web URL the event refers to in some way | ["r", <url>] |
NIP-24 |
Content handling & display
| Tag | Purpose | Structure | NIP |
|---|---|---|---|
subject |
Subject line for a text (kind 1) event, like an email subject | ["subject", <string>] |
NIP-14 |
content-warning |
Marks content that readers must approve before it is shown | ["content-warning", <reason, optional>] |
NIP-36 |
alt |
Short human-readable summary so generic clients can render an unknown kind | ["alt", <plaintext description>] |
NIP-31 |
emoji |
Custom emoji shortcode → image URL (kinds 0, 1, 7, 30315) | ["emoji", <shortcode>, <image-url>] |
NIP-30 |
imeta |
Inline metadata describing a media URL found in the content | ["imeta", "url ...", "m ...", "dim ...", …] |
NIP-92 |
Long-form article metadata (NIP-23)
| Tag | Purpose | NIP |
|---|---|---|
title |
The article title | NIP-23 |
image |
URL of an image shown with the title | NIP-23 |
summary |
The article summary | NIP-23 |
published_at |
Unix timestamp (stringified) of first publication | NIP-23 |
Protocol & lifecycle
| Tag | Purpose | Structure | NIP |
|---|---|---|---|
expiration |
Unix timestamp after which the event SHOULD be considered expired and deleted by relays | ["expiration", <unix timestamp>] |
NIP-40 |
nonce |
Proof-of-work: a mutable value tuned so the event id has the target leading-zero bits | ["nonce", <nonce>, <target difficulty>] |
NIP-13 |
Why the tag namespace matters
Two design points are worth internalising. First, single-letter tags are indexable — relays let clients filter on them (a #t hashtag search, a #p mentions feed, a #e thread lookup), which is why so much of Nostr’s social graph is expressed through e and p. Multi-character tags like content-warning or imeta carry local, per-event meaning and are generally not queried. Second, tags are how the protocol stays extensible without forking: a new NIP can define a new tag, and clients that don’t understand it simply ignore it — the alt tag exists precisely so that clients which don’t recognise a new kind can still show something sensible.
This registry pairs with our event-kinds reference (the kind namespace) and NIPs reference (the specifications) to cover the full NIP-01 data model. It sits in the wider protocol specifications hub alongside our Bitcoin, Lightning, and mesh references. New to the protocol? Start with Nostr for Bitcoiners, and generate or inspect keys with the Nostr key converter. For any tag’s full parameter list, the defining NIP in nostr-protocol/nips is authoritative.
