This is the full developer documentation for Web Monetization
# 404 - Page Not Found
> Page not found. Check the URL or try using the search bar.
# Activity Streams JSON-LD
Social web community servers and apps can expose the wallet address of a user or post to a Web Monetization client, such as Interledger Foundation’s [Web Monetization browser extension](/supporters/get-started#install-the-extension) or embedded SDK.
The `monetization` property from the Web Monetization namespace (`https://webmonetization.org/ns.jsonld`) applies to an [Activity Streams 2.0](https://www.w3.org/TR/activitystreams-core/) [`Object`](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-object).
A Web Monetization wallet address can be applied to either an [`Actor`](https://www.w3.org/TR/activitystreams-vocabulary/#actor-types) performing an action of creation or an [Object Type](https://www.w3.org/TR/activitystreams-vocabulary/#object-types) created by the `Actor`.
A `monetization` property must only be applied to an Object Type when its desired monetization attribution is distinct from the `Actor` who created it.
## User `Profile` example
[Section titled “User Profile example”](#user-profile-example)
```jsonc
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
// Add the Web Monetization context
"https://webmonetization.org/ns.jsonld",
{
"Hashtag": "as:Hashtag"
}
],
"id": "https://alpaca.gold/users/Jeremiah",
"type": "Person",
"following": "https://alpaca.gold/users/Jeremiah/following",
"followers": "https://alpaca.gold/users/Jeremiah/followers",
"inbox": "https://alpaca.gold/users/Jeremiah/inbox",
"outbox": "https://alpaca.gold/users/Jeremiah/outbox",
"preferredUsername": "Jeremiah",
"name": "Jeremiah Lee",
"summary": "
I can’t take full credit for the awesomeness of this post.
",
"replies": {
"id": "https://alpaca.gold/users/Jeremiah/statuses/816659822732776311/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://alpaca.gold/users/Jeremiah/statuses/816659822732776311/replies?only_other_accounts=true&page=true",
"partOf": "https://alpaca.gold/users/Jeremiah/statuses/816659822732776311/replies"
}
},
// Wallet address when viewing this Note
"monetization": ["https://fynbos.me/jeremiah", "https://fynbos.me/adam"]
}
```
# Content Security Policy (CSP)
A [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) is an extra layer of security that allows you to control the resources a user agent, such as a web browser, is allowed to load for a given page. CSPs use directives to describe the policies for a certain resource type.
The `monetization-src` fetch directive allows you to define the wallet address URLs that a browser can load. If an attempt is made to load an undefined URL, a network error will occur and the URL won’t load.
| CSP Version | 3 |
| -------------- | ------------------------------------------------------------------------------------ |
| Directive | `monetization-src` |
| Directive type | [Fetch directive](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_directive) |
## Syntax
[Section titled “Syntax”](#syntax)
```http
Content-Security-Policy: monetization-src ;
Content-Security-Policy: monetization-src , ;
```
Where `` is a wallet address that’s allowed to load.
```http
Content-Security-Policy: monetization-src https://example.com;
```
## Example
[Section titled “Example”](#example)
Your wallet address is `https://wallet.example.com/alice`. You want to ensure that no other URLs can be loaded.
You configure your web server to return the following `Content-Security-Policy` HTTP header on each applicable page of your website.
```http
Content-Security-Policy: monetization-src https://wallet.example.com/alice;
```
A bad actor injects their wallet address into your site.
```html
```
However, fetches for the injected URL will return a network error and not load because the URL doesn’t match what you’ve defined in your CSP.
// ## Browser compatibility
| | desktop | | | | | | mobile | | | | | | |
| ------------------ | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------ | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- |
| | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | WebView Android | Chrome Android | Firefox for Android | Opera Android | Safari on iOS | Samsung Internet | Puma Browser |
| `monetization-src` | Yes | Yes | Yes | No | Yes | No | No | No | No | No | No | No | Yes |
* 
Full Support
* 
No Support
* 
You'll need to use a Web Monetization Extension
## Specification
[Section titled “Specification”](#specification)
| Specification |
| ---------------------------------------------------------------------------------- |
| [Web Monetization#content-security-policy](/specification#content-security-policy) |
# Monetization events
Web Monetization API
One responsibility of the [Web Monetization agent](/resources/glossary/#web-monetization-agent) is to instrument payments. The agent does this by calling the Open Payments APIs, which are APIs implemented by wallet providers.
The agent makes calls to the [`/incoming-payments`](https://openpayments.dev/apis/resource-server/operations/create-incoming-payment/) endpoint at your wallet provider and to the [`/outgoing-payments`](https://openpayments.dev/apis/resource-server/operations/create-outgoing-payment/) endpoint at your site visitor’s wallet provider.
Each time the agent receives a `201 outgoing payment created` response from the site visitor’s wallet provider, the agent fires a `monetization` event on the browser window.
### Specification
[Section titled “Specification”](#specification)
| Specification |
| ------------------------------------------------ |
| [Web Monetization#events](/specification#events) |
## Event listeners
[Section titled “Event listeners”](#event-listeners)
When a `monetization` event fires, there’s no guarantee that payments will follow or, if they do, how often or how large the payments will be.
A `monetization` event indicates that the site visitor’s wallet provider has created the resources needed for it to send a payment.
By adding an event listener to the relevant monetization `` element (or one of its ancestors), you can use the `monetization` event properties to verify payments. These properties provide:
* Information about the [amount and currency](#amountsent) of a sent (not received) payment
* A URL representing an [incoming payment](#incomingpayment) that can be used to determine the amount received, similar to a receipt
* The URL representing the [wallet address](#walletaddress) that an incoming payment request was sent to
### High-level flow
[Section titled “High-level flow”](#high-level-flow)
1. You add an event listener to a monetization ``.
2. The site visitor accesses your page.
3. The site visitor’s Web Monetization agent calls the Open Payments APIs to begin setting up the payment. More information about these API calls can be found [here](/publishers/about-receiving#a-deeper-dive-into-payments).
4. The Web Monetization agent receives a `201 (outgoing payment created)` response from the site visitor’s wallet provider.
5. The Web Monetization agent fires a `monetization` event.
6. Your event listener calls its defined function.
## Event properties
[Section titled “Event properties”](#event-properties)
### amountSent
[Section titled “amountSent”](#amountsent)
The `amountSent` property returns the `value` and `currency` of the sent payment.
* `value` - The amount. A [valid decimal monetary value](https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value) containing the amount that was sent.
* `currency` - The currency code. A well-formed 3-letter [ISO4217](https://www.iban.com/currency-codes) code that represents the currency that was sent, such as USD (for US dollar) or GBP (for Great Britain Pound).
Example
```js
"value": "1.23"
"currency": "USD"
```
Received amount
The `amountSent` isn’t necessarily the amount received. For example, if your payment account is set up to receive GBP (Great Britain Pound), but your site visitor’s account sends in USD (US dollar), then exchange rates and currency conversion fees could affect the amount you receive.
#### Examples using `amountSent`
[Section titled “Examples using amountSent”](#examples-using-amountsent)
In this example, you have a single monetization link element and are listening for `monetization` events on the element.
```js
```
In this example, you have multiple link elements (not shown). You’re listening for `monetization` events on the `window`, which provides events for all monetization link elements on the page. The `event.target` will correspond to the relevant link element.
```js
```
// #### amountSent browser compatibility
| | desktop | | | | | | mobile | | | | | | |
| ------------ | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------ | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- |
| | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | WebView Android | Chrome Android | Firefox for Android | Opera Android | Safari on iOS | Samsung Internet | Puma Browser |
| `amountSent` | Yes | Yes | Yes | No | Yes | No | No | No | No | No | No | No | Yes |
* 
Full Support
* 
No Support
* 
You'll need to use a Web Monetization Extension
#### Specification
[Section titled “Specification”](#specification-1)
| Specification |
| ---------------------------------------------------------------------------- |
| [Web Monetization#amountsent-attribute](/specification#amountsent-attribute) |
### incomingPayment
[Section titled “incomingPayment”](#incomingpayment)
Experimental
`incomingPayment` is an [experimental technology](https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete#experimental).
The `incomingPayment` property allows you to check whether a payment was received and, if so, the amount received.
The property returns a URL that represents the incoming payment at your wallet provider. By querying the URL, you can get the `receivedAmount`.
#### Example using `incomingPayment`
[Section titled “Example using incomingPayment”](#example-using-incomingpayment)
This example shows a hypothetical verification method that makes a basic request to the `incomingPayment` URL and returns the results. For simplicity, it has no logic for authenticating the request.
Authentication
In many cases, requests to the `incomingPayment` URL must be authenticated because you’re fetching sensitive details. The payment account owner should request these specifics from their wallet provider.
```js
/** @type {MonetizationEvent} event */
async function verifyPayment(event) {
// Legacy receivers don't support returning incoming payment URLs
if (!event.incomingPayment) {
throw new Error('No incoming payment URL')
}
const response = await fetch(event.incomingPayment, {
method: 'GET',
credentials: 'same-origin',
mode: 'same-origin',
cache: 'no-cache',
headers: {
'Content-Type': 'application/json'
}
})
if (response.ok) {
const { receivedAmount } = JSON.parse(response.json())
const { amount, assetCode, assetScale } = receivedAmount
console.log(`Received ${assetCode}${amount / Math.pow(10, assetScale)}.`)
}
}
```
// #### incomingPayment browser compatibility
| | desktop | | | | | | mobile | | | | | | |
| ----------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------ | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- |
| | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | WebView Android | Chrome Android | Firefox for Android | Opera Android | Safari on iOS | Samsung Internet | Puma Browser |
| `incomingPayment` | Yes | Yes | Yes | No | Yes | No | No | No | No | No | No | No | Yes |
* 
Full Support
* 
No Support
* 
You'll need to use a Web Monetization Extension
#### Specification
[Section titled “Specification”](#specification-2)
| Specification |
| -------------------------------------------------------------------------------------- |
| [Web Monetization#incomingpayment-attribute](/specification#incomingpayment-attribute) |
### walletAddress
[Section titled “walletAddress”](#walletaddress)
The `walletAddress` property returns the URL that represents the wallet address that the payment was sent to. In most cases, the value will be the same as the `href` URL in the monetization ``.
Property naming history
Earlier versions of the Web Monetization specification only used Interledger’s Simple Payment Setup Protocol (SPSP), which calls for payment pointers. This is why the property was originally named `paymentPointer`.
As of the September 2026 spec update, `paymentPointer` is deprecated in favor of `walletAddress`. Both properties return the same value, but `walletAddress` should be used going forward.
#### Example using `walletAddress`
[Section titled “Example using walletAddress”](#example-using-walletaddress)
```js
```
#### Specification
[Section titled “Specification”](#specification-3)
| Specification |
| ---------------------------------------------------------------------------------- |
| [Web Monetization#walletaddress-attribute](/specification#walletaddress-attribute) |
### paymentPointer
[Section titled “paymentPointer”](#paymentpointer)
Deprecated
`paymentPointer` is [deprecated](https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete#deprecated_and_obsolete). Use [`walletAddress`](#walletaddress) instead.
The `paymentPointer` property returns the same URL as [`walletAddress`](#walletaddress). It’s retained for backward compatibility only and shouldn’t be used in new integrations.
// #### paymentPointer browser compatibility
| | desktop | | | | | | mobile | | | | | | |
| ---------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------ | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- |
| | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | WebView Android | Chrome Android | Firefox for Android | Opera Android | Safari on iOS | Samsung Internet | Puma Browser |
| `paymentPointer` | Yes | Yes | Yes | No | Yes | No | No | No | No | No | No | No | Yes |
* 
Full Support
* 
No Support
* 
You'll need to use a Web Monetization Extension
#### Specification
[Section titled “Specification”](#specification-4)
| Specification |
| ------------------------------------------------------------------------------------ |
| [Web Monetization#paymentpointer-attribute](/specification#paymentpointer-attribute) |
## Example use cases
[Section titled “Example use cases”](#example-use-cases)
### amountSent
[Section titled “amountSent”](#amountsent-1)
Program your website to show a thank you message to your site visitor when the `amountSent` returns a non-zero amount. In this use case, you’re only checking that an amount — any amount — was sent.
### incomingPayment
[Section titled “incomingPayment”](#incomingpayment-1)
Program your website to remove ads or provide access to exclusive content to your site visitor after receiving a specific amount.
In this use case, you’ll query the URL returned by `incomingPayment` to track the `receivedAmount`. If appropriate, you can ensure the amount is increasing after each `monetization` event to verify that a new payment was received.
### walletAddress
[Section titled “walletAddress”](#walletaddress-1)
This section describes two use cases: one for vanity payment addresses and one for probabilistic revenue sharing.
#### Vanity payment address
[Section titled “Vanity payment address”](#vanity-payment-address)
Let’s say your wallet address is:
```plaintext
https://wallet.example.com/GK9D420BL42M
```
That’s hard to remember. Fortunately, your wallet provider offers vanity addresses which act as aliases. Your vanity address is:
```plaintext
https://wallet.example.com/bob
```
You add the vanity address as the `href` value in the monetization ``. Then, you set up an event listener for `walletAddress`. The value that’s returned will be:
```plaintext
https://wallet.example.com/GK9D420BL42M
```
#### Probabilistic revenue sharing
[Section titled “Probabilistic revenue sharing”](#probabilistic-revenue-sharing)
For this use case, let’s assume you are familiar with [probabilistic revenue sharing](/tutorials/revenue-sharing), which is itself an advanced use case.
When you use our [Probabilistic Revshare Generator](https://webmonetization.org/prob-revshare/), you enter multiple wallet addresses and assign each one a weight. When finished, the generator creates a unique URL.
For example, after entering five wallet addresses and weights, the generator creates:
```http
https://webmonetization.org/api/revshare/pay/W1siJGFsaWNlLndhbGxldC5jb20iLDUwLCIkYWxpY2"
```
You add the generated URL as the `href` value in the monetization ``. Then, you set up an event listener for `walletAddress`. The value that’s returned will be which one of the five wallet addresses that the payment was sent to.
# Monetization interfaces
Web Monetization API
The Web Monetization API consists of two interfaces: `MonetizationEvent` and `MonetizationCurrencyAmount`.
## MonetizationEvent
[Section titled “MonetizationEvent”](#monetizationevent)
The `MonetizationEvent` interface describes the [`monetization`](/developers/events) event that fires when an outgoing payment is successfully created.
| Bubbles | Yes |
| ---------------------- | ---------------- |
| Cancelable | No |
| Event handler property | `onmonetization` |
By listening for `monetization` events, you can use the information returned in the following properties to verify payments.
| Property | Description |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [amountSent](/developers/events#amountsent) | The currency amount and code of the sent payment. Contains two variables, `value` and `currency`, constructed by the [`MonetizationCurrencyAmount`](#monetizationcurrencyamount) interface. |
| [incomingPayment](/developers/events#incomingpayment) | A URL you can use to determine if a payment was received and, if so, the amount received. |
| [walletAddress](/developers/events#walletaddress) | The URL of the wallet address that the incoming payment request was sent to. |
| [paymentPointer](/developers/events#paymentpointer) Deprecated | Deprecated alias for `walletAddress`. Retained for backward compatibility only. |
Visit the [Monetization events](/developers/events) page for more information.
// ## Browser compatibility
| | desktop | | | | | | mobile | | | | | | |
| ------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------- | ------------------------------------------ | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- | --------------------------------------- |
| | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | WebView Android | Chrome Android | Firefox for Android | Opera Android | Safari on iOS | Samsung Internet | Puma Browser |
| `MonetizationEvent` | Yes | Yes | Yes | No | Yes | No | No | No | No | No | No | No | Yes |
* 
Full Support
* 
No Support
* 
You'll need to use a Web Monetization Extension
### Specification
[Section titled “Specification”](#specification)
| Specification |
| ------------------------------------------------------------------------------------------ |
| [Web Monetization#monetizationevent-interface](/specification#monetizationevent-interface) |
## MonetizationCurrencyAmount
[Section titled “MonetizationCurrencyAmount”](#monetizationcurrencyamount)
The `MonetizationCurrencyAmount` interface is used to populate the `value` and `currency` variables contained within the `MonetizationEvent amountSent` property.
* Value - The amount. A valid decimal monetary value containing the amount that was sent.
* Currency - The currency code. An ISO 4217-compliant currency code, when possible, that represents the currency that was sent. For example, USD (for US dollar) or GBP (for Great Britain Pound).
The `MonetizationCurrencyAmount` interface is modeled on the Payment Request API’s [`PaymentCurrencyAmount`](https://www.w3.org/TR/payment-request/#paymentcurrencyamount-dictionary) dictionary.
### Specification
[Section titled “Specification”](#specification-1)
| Specification |
| ------------------------------------------------------------------------------------------------------------ |
| [Web Monetization#monetizationcurrencyamount-interface](/specification#monetizationcurrencyamount-interface) |
# Libraries
The most recent draft of the [Web Monetization specification (v2.0)](https://webmonetization.org/specification/) introduced updates to be more consistent with the design of other browser features. As a result, libraries that implemented v1.0 of the specification need code updates to be compatible with v2.0.
We encourage the community to support the Web Monetization ecosystem by updating existing tools/libraries to be compatible with the latest spec and by creating new tools and plugins for frameworks and libraries.
For more information, check out Santosh’s [developer guide](https://community.interledger.org/devcer/developer-guide-to-migrating-the-breaking-changes-in-the-latest-web-monetization-draft-cj2) to migrating the breaking changes in the latest Web Monetization draft.
| Name | v2.0 | v1.0 | GitHub |
| -------------------------------------------------------------------------------------------------------------------- | ---- | ---- | ------------------------------------------------------------------- |
| **Astro Monetization** This Astro component simplifies the process of adding monetization links to your Astro sites. | ✅ | ❌ | [](https://github.com/devcer/astro-monetization) |
| **react-monetize** Helpers and hooks to speed up your integration with Web Monetization API | ✅ | ✅ | [](https://github.com/guidovizoso/react-monetize) |
| **Monetize 11ty** An Eleventy plugin to monetize posts and site content by creating exclusive content areas | ✅ | ✅ | [](https://github.com/devcer/eleventy-plugin-monetization) |
| **Hugo Web Monetization Component** Theme component that enables Web Monetization on your entire Hugo website | ❌ | ✅ | [](https://github.com/sabinebertram/hugo-webmonetization-component) |
| **gridsome-plugin-monetization** Web Monetization plugin for Gridsome | ❌ | ✅ | [](https://github.com/Sergix/gridsome-plugin-monetization) |
| **gatsby-plugin-monetization** A Gatsby plugin for react-monetize to speed up your integration with Web Monetization | ❌ | ✅ | [](https://github.com/mrmuhammadali/gatsby-plugin-monetization) |
| **ngx-monetization** Web Monetization API for Angular | ❌ | ✅ | [](https://github.com/CDDelta/ngx-monetization) |
| **Vuepress Plugin Web-Monetization** Adds a Web Monetization meta tag to your VuePress website | ❌ | ✅ | [](https://github.com/spekulatius/vuepress-plugin-web-monetization) |
| **Tessy** Advanced Web Monetization testing library with powerful declarative API | ❌ | ✅ | [](https://github.com/VladimirMikulic/tessy) |
| **svelte-monetization** A minimal and lightweight wrapper for the Web Monetization API | ❌ | ✅ | [](https://github.com/sorxrob/svelte-monetization) |
| **Moodle Webmonetization Module** A plugin for adding a web monetization meta tag to your Moodle site | ❌ | ✅ | [](https://github.com/andrewhancox/moodle-local_webmonetization) |
| **Jekyll + Webmonetization** A Jekyll plugin for adding a Web Monetization meta tag to your site | ❌ | ✅ | [](https://github.com/philnash/jekyll-web_monetization) |
| **Pipe Web Monetization** Web monetize your WordPress website and access your revenue via an analytics dashboard | ❌ | ✅ | [](https://www.pipewebmonetization.com/) |
# Monetization element
HTML DOM API
From a content owner/developer perspective, the monetization `` element is one of the two key pieces to web monetizing an HTML page. The second piece is a wallet address.
## Prerequisites
[Section titled “Prerequisites”](#prerequisites)
To web monetize an HTML page:
* You must have an account with a [compatible wallet provider](/wallets)
* You must have the wallet address from your wallet provider
* Your document must be served over HTTPS
## Monetization `` element
[Section titled “Monetization \ element”](#monetization-link-element)
### Syntax
[Section titled “Syntax”](#syntax)
```html
```
* The `rel` attribute is always `monetization`
* The `href` attribute equals your wallet address
For example:
```html
```
### Placement
[Section titled “Placement”](#placement)
A monetization `` is `body-ok`, meaning it’s allowed in your page’s `` and/or ``.
### Multiple monetization links
[Section titled “Multiple monetization links”](#multiple-monetization-links)
An HTML page can contain multiple monetization `` elements, but your site visitor’s Web Monetization agent could be designed to handle multiple links in a particular way. For example, an agent could:
* Split payments evenly between all links
* Split payments between the first few links it finds
* Send the amount only to the first link it finds and ignore all others
The Web Monetization agent built into the [Interledger Foundation’s extension](https://github.com/interledger/web-monetization-extension) splits payments evenly between all links, even if the same wallet address is used in multiple links.
Recommendation
We recommend other extension developers follow this approach.
### Iframes
[Section titled “Iframes”](#iframes)
Nested browsing contexts (iframes) can contain monetization `` elements, but your site visitor’s Web Monetization agent determines how iframes are monetized. A few examples of how a Web Monetization agent can monetize iframes include:
* Splitting payments evenly between all monetization links in both the parent and the iframe
* Sending payments to the first monetization link it finds in the parent browsing context and ignoring all other monetization links in the parent and the iframe
* Splitting payments evenly between all monetization links in the parent and the first monetization link it finds in the iframe’s ``, while ignoring any other monetization links in the iframe
Note
This last approach is used in the [Interledger Foundation’s extension](https://github.com/interledger/web-monetization-extension).
### Audio, video, and picture elements
[Section titled “Audio, video, and picture elements”](#audio-video-and-picture-elements)
The following HTML elements can be web monetized by adding the `` element between the open and close tags.
* \