---
title: Line protocol reference
description: InfluxDB 3 Cloud uses line protocol to write data points. It is a text-based format that provides the table, tag set, field set, and timestamp of a data point.
url: https://docs.influxdata.com/influxdb3/cloud/reference/syntax/line-protocol/
estimated_tokens: 3697
product: InfluxDB 3 Cloud
version: cloud
publisher: InfluxData
canonical: https://docs.influxdata.com/influxdb3/cloud/reference/syntax/line-protocol/
date: '2026-07-22T11:37:02-05:00'
lastmod: '2026-07-22T11:37:02-05:00'
---

InfluxDB 3 Cloud uses line protocol to write data points.
It is a text-based format that provides the table, tag set, field set, and
timestamp of a data point.

* [Elements of line protocol](#elements-of-line-protocol)
* [Data types and format](#data-types-and-format)
* [Quotes](#quotes)
* [Special characters](#special-characters)
* [Comments](#comments)
* [Naming restrictions](#naming-restrictions)
* [Duplicate points](#duplicate-points)

```text
# Syntax
<table>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]
```

```lp
myTable,tag1=value1,tag2=value2 fieldKey="fieldValue" 1556813561098000000
```

Lines separated by the newline character `\n` represent a single point
in InfluxDB. Line protocol is whitespace-sensitive.

> [!Note]
> Line protocol does not support the newline character `\n` in tag or field values.

## Elements of line protocol

myTable,tag1=val1,tag2=val2 field1="v1",field2=1i 0000000000000000000

### Table

(Required)
The table name.
InfluxDB accepts one table per point.*Table names are case-sensitive and subject to [naming restrictions](#naming-restrictions).*

***Data type:** [String](#string)*

> [!Note]
> If familiar with previous InfluxDB versions, “**table**” is synonymous with
> “**measurement**.”

### Tag set

(***Optional***)
All tag key-value pairs for the point.
Key-value relationships are denoted with the `=` operand.
Multiple tag key-value pairs are comma-delimited.*Tag keys and tag values are case-sensitive.
Tag keys are subject to [naming restrictions](#naming-restrictions).
Tag values cannot be empty; instead, omit the tag from the tag set.*

***Key data type:** [String](#string)*  
***Value data type:** [String](#string)*

### Field set

(Required)
All field key-value pairs for the point.
Points must have at least one field.*Field keys and string values are case-sensitive.
Field keys are subject to [naming restrictions](#naming-restrictions).*

***Key data type:** [String](#string)*  
***Value data type:** [Float](#float) | [Integer](#integer) | [UInteger](#uinteger) | [String](#string) | [Boolean](#boolean)*

> [!Note]
> *Always double quote string field values. More on quotes [below](#quotes).*
>
> ```
> tableName fieldKey="field string value" 1556813561098000000
> ```

### Timestamp

(***Optional***)
The [Unix timestamp](/influxdb3/cloud/reference/glossary/#unix-timestamp) for the data point.
InfluxDB accepts one timestamp per point.
If no timestamp is provided, InfluxDB uses the system time (UTC) of its host machine.

***Data type:** [Unix timestamp](#unix-timestamp)*

> [!Note]
> #### Important notes about timestamps
>
> * To ensure a data point includes the time a metric is observed (not received by InfluxDB),
> include the timestamp.
> * If your timestamps are not in nanoseconds, specify the precision of your timestamps
> when writing the data to InfluxDB 3 Cloud.

### Whitespace

Whitespace in line protocol determines how InfluxDB interprets the data point.
The **first unescaped space** delimits the table and the tag set from the field set.
The **second unescaped space** delimits the field set from the timestamp.

myTable,tag1=val1,tag2=val2 field1="v1",field2=1i 0000000000000000000

## Data types and format

### Float

IEEE-754 64-bit floating-point numbers.
Default numerical type.*InfluxDB supports scientific notation in float field values.*

##### Float field value examples

```lp
myTable fieldKey=1.0
myTable fieldKey=1
myTable fieldKey=-1.234456e+78
```

### Integer

Signed 64-bit integers.
Trailing `i` on the number specifies an integer.

|    Minimum integer    |   Maximum integer    |
|-----------------------|----------------------|
|`-9223372036854775808i`|`9223372036854775807i`|

##### Integer field value examples

```lp
myTable fieldKey=1i
myTable fieldKey=12485903i
myTable fieldKey=-12485903i
```

### UInteger

Unsigned 64-bit integers.
Trailing `u` on the number specifies an unsigned integer.

|Minimum uinteger|   Maximum uinteger    |
|----------------|-----------------------|
|      `0u`      |`18446744073709551615u`|

##### UInteger field value examples

```lp
myTable fieldKey=1u
myTable fieldKey=12485903u
```

### String

Plain text string.

|                 Element                 |Maximum length|
|-----------------------------------------|--------------|
|Table name, tag key, tag value, field key|     64KB     |
|               Field value               |     1MB      |

##### String example

```lp
# String table name, field key, and field value
myTable fieldKey="this is a string"
```

### Boolean

Stores `true` or `false` values.

|Boolean value|          Accepted syntax          |
|-------------|-----------------------------------|
|    True     | `t`, `T`, `true`, `True`, `TRUE`  |
|    False    |`f`, `F`, `false`, `False`, `FALSE`|

##### Boolean field value examples

```lp
myTable fieldKey=true
myTable fieldKey=false
myTable fieldKey=t
myTable fieldKey=f
myTable fieldKey=TRUE
myTable fieldKey=FALSE
```

> [!Note]
> Do not quote boolean field values.
> Quoted field values are interpreted as strings.

### Unix timestamp

Unix timestamp in a [specified precision](/influxdb3/cloud/reference/glossary/#unix-timestamp).
Default precision is nanoseconds (`ns`).

|  Minimum timestamp   |  Maximum timestamp  |
|----------------------|---------------------|
|`-9223372036854775806`|`9223372036854775806`|

##### Unix timestamp example

```lp
myTableName fieldKey="fieldValue" 1556813561098000000
```

## Quotes

Line protocol supports single and double quotes as described in the following table:

|  Element  |             Double quotes             |             Single quotes             |
|-----------|---------------------------------------|---------------------------------------|
|   Table   |*Limited* <sup class="required">*</sup>|*Limited* <sup class="required">*</sup>|
|  Tag key  |*Limited* <sup class="required">*</sup>|*Limited* <sup class="required">*</sup>|
| Tag value |*Limited* <sup class="required">*</sup>|*Limited* <sup class="required">*</sup>|
| Field key |*Limited* <sup class="required">*</sup>|*Limited* <sup class="required">*</sup>|
|Field value|           **Strings only**            |                 Never                 |
| Timestamp |                 Never                 |                 Never                 |

<sup class="required">*</sup> *Line protocol accepts double and single quotes in
table names, tag keys, tag values, and field keys, but interprets them as
part of the name, key, or value.*

## Special Characters

Line protocol supports special characters in [string elements](#string).
In the following contexts, it requires escaping certain characters with a backslash (`\`):

|  Element  |    Escape characters    |
|-----------|-------------------------|
|   Table   |      Comma, Space       |
|  Tag key  |Comma, Equals Sign, Space|
| Tag value |Comma, Equals Sign, Space|
| Field key |Comma, Equals Sign, Space|
|Field value| Double quote, Backslash |

You do not need to escape other special characters.

##### Examples of special characters in line protocol

```lp
# Table name with spaces
my\ Table fieldKey="string value"

# Double quotes in a string field value
myTable fieldKey="\"string\" within a string"

# Tag keys and values with spaces
myTable,tag\ Key1=tag\ Value1,tag\ Key2=tag\ Value2 fieldKey=100

# Emojis
myTable,tagKey=🍭 fieldKey="Launch 🚀" 1556813561098000000
```

### Escaping backslashes

Line protocol supports both literal backslashes and backslashes as an escape character.
With two contiguous backslashes, the first is interpreted as an escape character.
For example:

|Backslashes|Interpreted as|
|-----------|--------------|
|    `\`    |     `\`      |
|   `\\`    |     `\`      |
|   `\\\`   |     `\\`     |
|  `\\\\`   |     `\\`     |
|  `\\\\\`  |    `\\\`     |
| `\\\\\\`  |    `\\\`     |

## Comments

Line protocol interprets `#` at the beginning of a line as a comment character
and ignores all subsequent characters until the next newline `\n`.

```lp
# This is a comment
myTable fieldKey="string value" 1556813561098000000
```

## Naming restrictions

Table names, tag keys, and field keys are alphanumeric and must begin with a
letter or a number. They can contain dashes (`-`) and underscores (`_`).

## Duplicate points

A point is uniquely identified by the table name, tag set, and timestamp.
If you submit line protocol with the same table, tag set, and timestamp,
InfluxDB stores a single point for that identity, merging the field sets of the
duplicate writes.
When duplicate writes set the same field, InfluxDB does not guarantee which
value is retained.
Read the following warning before relying on overwrites to maintain a last-value view.

> [!Warning]
> #### Overwrites are not deterministic
>
> Overwriting a point (same table, tag set, and timestamp) is not reliable in
> InfluxDB 3 Cloud, regardless of the delay between writes: queries may
> return either version, and either version may be permanently stored.
> Which version is retained depends on write rate, buffer and snapshot timing,
> compaction state, and, in clusters with multiple ingest nodes, which node
> received each write.
>
> To maintain a last-value view, use the [append-only patterns](#recommended-patterns-for-last-value-tracking)instead of overwrites.

### Recommended patterns for last-value tracking

To reliably maintain a last-value view of your data, use one of these append-only patterns:

#### Append-only with unique timestamps (recommended)

Write each change as a new point with a unique timestamp using the actual event time.
Query for the most recent point to get the current value.

**Line protocol example**:

```text
device_status,device_id=sensor01 status="active",temperature=72.5 1700000000000000000
device_status,device_id=sensor01 status="active",temperature=73.1 1700000300000000000
device_status,device_id=sensor01 status="inactive",temperature=73.1 1700000600000000000
```

**SQL query to get latest state**:

```sql
SELECT
  device_id,
  status,
  temperature,
  time
FROM device_status
WHERE time >= now() - INTERVAL '7 days'
  AND device_id = 'sensor01'
ORDER BY time DESC
LIMIT 1
```

**InfluxQL query to get latest state**:

```influxql
SELECT LAST(status), LAST(temperature)
FROM device_status
WHERE device_id = 'sensor01'
  AND time >= now() - 7d
GROUP BY device_id
```

#### Append-only with change tracking field

If you need to filter by “changes since a specific time,” add a dedicated `last_change_timestamp` field.

**Line protocol example**:

```text
device_status,device_id=sensor01 status="active",temperature=72.5,last_change_timestamp=1700000000000000000i 1700000000000000000
device_status,device_id=sensor01 status="active",temperature=73.1,last_change_timestamp=1700000300000000000i 1700000300000000000
device_status,device_id=sensor01 status="inactive",temperature=73.1,last_change_timestamp=1700000600000000000i 1700000600000000000
```

**SQL query to get changes since a specific time**:

```sql
SELECT
  device_id,
  status,
  temperature,
  time
FROM device_status
WHERE last_change_timestamp >= 1700000000000000000
ORDER BY time DESC
```

### Anti-patterns to avoid

The following patterns will produce non-deterministic results when duplicate points are flushed together:

#### Don’t overwrite the same (time, tags) point

If points with the same time and tag set are flushed to storage together, any of the values might be retained.
For example, **don’t do this**:

```text
-- All writes use the same timestamp
device_status,device_id=sensor01 status="active",temperature=72.5 1700000000000000000
device_status,device_id=sensor01 status="active",temperature=73.1 1700000000000000000
device_status,device_id=sensor01 status="inactive",temperature=73.1 1700000000000000000
```

#### Don’t add a field while overwriting data (time, tags)

Adding a field doesn’t make points unique.
Points with the same time and tag set are still considered duplicates–for example,**don’t do this**:

```text
-- All writes use the same timestamp, but add a version field
device_status,device_id=sensor01 status="active",temperature=72.5,version=1i 1700000000000000000
device_status,device_id=sensor01 status="active",temperature=73.1,version=2i 1700000000000000000
device_status,device_id=sensor01 status="inactive",temperature=73.1,version=3i 1700000000000000000
```

#### Don’t rely on short write delays to force ordering

Short delays don’t guarantee that duplicate points won’t be flushed together.
The flush interval depends on buffer size, ingestion rate, and system load.

In InfluxDB 3 Cloud, overwrite resolution is never deterministic, regardless of delay length; use the append-only patterns instead.

For example, **don’t do this**:

```text
-- Writing with delays between each write
device_status,device_id=sensor01 status="active" 1700000000000000000
# Wait 10 seconds...
device_status,device_id=sensor01 status="inactive" 1700000000000000000
```

Append-only patterns increase row count.
See [Create a database](/influxdb3/cloud/admin/databases/create/) to configure shorter retention for last-value data.

#### Related

* [Write data to InfluxDB 3 Cloud](/influxdb3/cloud/write-data/)
| Minimum integer | Maximum integer |
| --- | --- |
| Minimum integer | Maximum integer |
| -9223372036854775808i | 9223372036854775807i |

| Minimum uinteger | Maximum uinteger |
| --- | --- |
| Minimum uinteger | Maximum uinteger |
| 0u | 18446744073709551615u |

| Element | Maximum length |
| --- | --- |
| Element | Maximum length |
| Table name, tag key, tag value, field key | 64KB |
| Field value | 1MB |

| Boolean value | Accepted syntax |
| --- | --- |
| Boolean value | Accepted syntax |
| True | t ,  T ,  true ,  True ,  TRUE |
| False | f ,  F ,  false ,  False ,  FALSE |

| Minimum timestamp | Maximum timestamp |
| --- | --- |
| Minimum timestamp | Maximum timestamp |
| -9223372036854775806 | 9223372036854775806 |

| Element | Double quotes | Single quotes |
| --- | --- | --- |
| Element | Double quotes | Single quotes |
| Table | Limited   * | Limited   * |
| Tag key | Limited   * | Limited   * |
| Tag value | Limited   * | Limited   * |
| Field key | Limited   * | Limited   * |
| Field value | Strings only | Never |
| Timestamp | Never | Never |

| Element | Escape characters |
| --- | --- |
| Element | Escape characters |
| Table | Comma, Space |
| Tag key | Comma, Equals Sign, Space |
| Tag value | Comma, Equals Sign, Space |
| Field key | Comma, Equals Sign, Space |
| Field value | Double quote, Backslash |

| Backslashes | Interpreted as |
| --- | --- |
| Backslashes | Interpreted as |
| \ | \ |
| \\ | \ |
| \\\ | \\ |
| \\\\ | \\ |
| \\\\\ | \\\ |
| \\\\\\ | \\\ |