diff --git a/SUMMARY.md b/SUMMARY.md
index d61397a29..ba6d33fd5 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -125,12 +125,12 @@
   * [Windows exporter metrics](pipeline/inputs/windows-exporter-metrics.md)
   * [Windows System Statistics (winstat)](pipeline/inputs/windows-system-statistics.md)
 * [Parsers](pipeline/parsers.md)
-  * [Configuring parsers](pipeline/parsers/configuring-parser.md)
-  * [Decoders](pipeline/parsers/decoders.md)
-  * [JSON](pipeline/parsers/json.md)
-  * [Logfmt](pipeline/parsers/logfmt.md)
-  * [LTSV](pipeline/parsers/ltsv.md)
-  * [Regular expression](pipeline/parsers/regular-expression.md)
+  * [Configuring custom parsers](pipeline/parsers/configuring-parser.md)
+  * [JSON format](pipeline/parsers/json.md)
+  * [Logfmt format](pipeline/parsers/logfmt.md)
+  * [LTSV format](pipeline/parsers/ltsv.md)
+  * [Regular expression format](pipeline/parsers/regular-expression.md)
+  * [Decoder settings](pipeline/parsers/decoders.md)
 * [Processors](pipeline/processors.md)
   * [Content modifier](pipeline/processors/content-modifier.md)
   * [Labels](pipeline/processors/labels.md)
diff --git a/administration/configuring-fluent-bit/yaml.md b/administration/configuring-fluent-bit/yaml.md
index f0edf6957..f352ab545 100644
--- a/administration/configuring-fluent-bit/yaml.md
+++ b/administration/configuring-fluent-bit/yaml.md
@@ -8,14 +8,14 @@ don't support, like processors.
 
 YAML configuration files support the following top-level sections:
 
-- `env`: Configures [environment variables](./yaml/environment-variables-section).
-- `includes`: Specifies additional YAML configuration files to [include as part of a parent file](./yaml/includes-section).
-- `service`: Configures global properties of the Fluent Bit [service](./yaml/service-section).
-- `pipeline`: Configures active [`inputs`, `filters`, and `outputs`](./yaml/pipeline-section).
-- `parsers`: Defines [custom parsers](./yaml/parsers-section).
-- `multiline_parsers`: Defines [custom multiline parsers](./yaml/multiline-parsers-section).
-- `plugins`: Defines paths for [custom plugins](./yaml/plugins-section).
-- `upstream_servers`: Defines [nodes](./yaml/upstream-servers-section) for output plugins.
+- `env`: Configures [environment variables](../administration/configuring-fluent-bit/yaml/environment-variables-section.md).
+- `includes`: Specifies additional YAML configuration files to [include as part of a parent file](../administration/configuring-fluent-bit/yaml/includes-section.md).
+- `service`: Configures global properties of the Fluent Bit [service](../administration/configuring-fluent-bit/yaml/service-section.md).
+- `pipeline`: Configures active [`inputs`, `filters`, and `outputs`](../administration/configuring-fluent-bit/yaml/pipeline-section.md).
+- `parsers`: Defines [custom parsers](../administration/configuring-fluent-bit/yaml/parsers-section.md).
+- `multiline_parsers`: Defines [custom multiline parsers](../administration/configuring-fluent-bit/yaml/multiline-parsers-section.md).
+- `plugins`: Defines paths for [custom plugins](../administration/configuring-fluent-bit/yaml/plugins-section.md).
+- `upstream_servers`: Defines [nodes](../administration/configuring-fluent-bit/yaml/upstream-servers-section.md) for output plugins.
 
 {% hint style="info" %}
 YAML configuration is used in the smoke tests for containers. An always-correct up-to-date example is here: <https://github.com/fluent/fluent-bit/blob/master/packaging/testing/smoke/container/fluent-bit.yaml>.
diff --git a/administration/configuring-fluent-bit/yaml/parsers-section.md b/administration/configuring-fluent-bit/yaml/parsers-section.md
index 18198e11e..c8df40c1e 100644
--- a/administration/configuring-fluent-bit/yaml/parsers-section.md
+++ b/administration/configuring-fluent-bit/yaml/parsers-section.md
@@ -1,23 +1,86 @@
 # Parsers
 
-Parsers enable Fluent Bit components to transform unstructured data into a structured internal representation. You can define YAML parsers either directly in the main configuration file or in separate external files for better organization.
+You can define customer [parsers](../pipeline/parsers.md) in the `parsers` section of YAML configuration files.
 
-This page provides a general overview of how to declare parsers.
+{% hint style="info" %}
 
-The main section name is `parsers`, and it lets you define a list of parser configurations. The following example demonstrates how to set up two basic parsers:
+To define custom multiline parsers, use [the `multiline_parsers` section](../administration/configuring-fluent-bit/yaml/multiline-parsers-section.md) of YAML configuration files.
+
+{% endhint %}
+
+## Syntax
+
+To define customers parsers in the `parsers` section of a YAML configuration file, use the following syntax.
+
+{% tabs %}
+{% tab title="fluent-bit.yaml" %}
 
 ```yaml
 parsers:
-  - name: json
+  - name: custom_parser1
     format: json
+    time_key: time
+    time_format: '%Y-%m-%dT%H:%M:%S.%L'
+    time_keep: on
+
+  - name: custom_parser2
+    format: regex
+    regex: '^\<(?<pri>[0-9]{1,5})\>1 (?<time>[^ ]+) (?<host>[^ ]+) (?<ident>[^ ]+) (?<pid>[-0-9]+) (?<msgid>[^ ]+) (?<extradata>(\[(.*)\]|-)) (?<message>.+)$'
+    time_key: time
+    time_format: '%Y-%m-%dT%H:%M:%S.%L'
+    time_keep: on
+    types: pid:integer
+```
+
+{% endtab %}
+{% endtabs %}
+
+For information about supported configuration options for custom parsers, see [configuring parsers](../pipeline/parsers/configuring-parser.md).
+
+## Standalone parsers files
+
+In addition to defining parsers in the `parsers` section of YAML configuration files, you can store parser definitions in standalone files. These standalone files require the same syntax as parsers defined in a standard YAML configuration file.
+
+To add a standalone parsers file to Fluent Bit, use the `parsers_file` parameter in the `service` section of your YAML configuration file.
 
-  - name: docker
+### Add a standalone parsers file to Fluent Bit
+
+To add a standalone parsers file to Fluent Bit, follow these steps.
+
+1. Define custom parsers in a standalone YAML file. For example, `my-parsers.yaml` defines two custom parsers:
+
+{% tabs %}
+{% tab title="my-parsers.yaml" %}
+
+```yaml
+parsers:
+  - name: custom_parser1
     format: json
     time_key: time
-    time_format: "%Y-%m-%dT%H:%M:%S.%L"
-    time_keep: true
+    time_format: '%Y-%m-%dT%H:%M:%S.%L'
+    time_keep: on
+
+  - name: custom_parser2
+    format: regex
+    regex: '^\<(?<pri>[0-9]{1,5})\>1 (?<time>[^ ]+) (?<host>[^ ]+) (?<ident>[^ ]+) (?<pid>[-0-9]+) (?<msgid>[^ ]+) (?<extradata>(\[(.*)\]|-)) (?<message>.+)$'
+    time_key: time
+    time_format: '%Y-%m-%dT%H:%M:%S.%L'
+    time_keep: on
+    types: pid:integer
 ```
 
-You can define multiple parsers sections, either within the main configuration file or distributed across included files.
+{% endtab %}
+{% endtabs %}
+
+1. Update the `parsers_file` parameter in the `service` section of your YAML configuration file:
+
+{% tabs %}
+{% tab title="fluent-bit.yaml" %}
+
+```yaml
+service:
+  parsers_file: my-parsers.yaml
+```
 
-For more detailed information on parser options and advanced configurations, refer to the [Configuring Parsers](../../../pipeline/parsers/configuring-parser.md) documentation.
+{% endtab %}
+{% endtabs %}
diff --git a/administration/configuring-fluent-bit/yaml/pipeline-section.md b/administration/configuring-fluent-bit/yaml/pipeline-section.md
index e14647386..66f8a9885 100644
--- a/administration/configuring-fluent-bit/yaml/pipeline-section.md
+++ b/administration/configuring-fluent-bit/yaml/pipeline-section.md
@@ -65,7 +65,7 @@ pipeline:
 
 In the cases where each value in a list requires two values they must be separated by a space, such as in the `record` property for the `record_modifier` filter.
 
-### Input
+### Inputs
 
 An `input` section defines a source (related to an input plugin). Each section has a base configuration. Each input plugin can add it own configuration keys:
 
@@ -88,7 +88,7 @@ pipeline:
           tag: my_cpu
 ```
 
-### Filter
+### Filters
 
 A `filter` section defines a filter (related to a filter plugin). Each section has a base configuration and each filter plugin can add its own configuration keys:
 
@@ -113,7 +113,7 @@ pipeline:
           regex: log aa
 ```
 
-### Output
+### Outputs
 
 The `outputs` section specifies a destination that certain records should follow after a `Tag` match. Fluent Bit can route up to 256 `OUTPUT` plugins. The configuration supports the following keys:
 
diff --git a/administration/configuring-fluent-bit/yaml/service-section.md b/administration/configuring-fluent-bit/yaml/service-section.md
index 851bef2f7..84925b3d9 100644
--- a/administration/configuring-fluent-bit/yaml/service-section.md
+++ b/administration/configuring-fluent-bit/yaml/service-section.md
@@ -2,7 +2,6 @@
 
 The `service` section defines global properties of the service. The available configuration keys are:
 
-
 | Key | Description | Default Value |
 | --- | ----------- | ------------- |
 | `flush`  | Sets the flush time in `seconds.nanoseconds`. The engine loop uses a flush timeout to define when to flush the records ingested by input plugins through the defined output plugins. | `1` |
@@ -11,9 +10,9 @@ The `service` section defines global properties of the service. The available co
 | `dns.mode` | Sets the primary transport layer protocol used by the asynchronous DNS resolver. Can be overridden on a per-plugin basis. | `UDP` |
 | `log_file` | Absolute path for an optional log file. By default, all logs are redirected to the standard error interface (`stderr`). | _none_ |
 | `log_level` | Sets the logging verbosity level. Possible values: `off`, `error`, `warn`, `info`, `debug`, and `trace`. Values are cumulative. For example, if `debug` is set, it will include `error`, `warning`, `info`, and `debug`. The `trace` mode is only available if Fluent Bit was built with the `WITH_TRACE` option enabled. | `info` |
-| `parsers_file` | Path for a parsers configuration file. Multiple `parsers_file` entries can be defined within the section. Parsers can be declared directly in the [`parsers` section](./parsers-section.md) of YAML configuration files. | _none_ |
-| `plugins_file` | Path for a `plugins` configuration file. This file specifies the paths to custom plugins (.so files) that Fluent Bit can load at runtime. Plugins can be declared directly in the [`plugins` section](./plugins-section.md) of YAML configuration files. | _none_ |
-| `streams_file` | Path for the [stream processor](../../../stream-processing/overview.md) configuration file. This file defines the rules and operations for stream processing in Fluent Bit. Stream processor configurations can also be defined directly in the `streams` section of YAML configuration files. | _none_ |
+| `parsers_file` | Path for [standalone parsers configuration files](../administration/configuring-fluent-bit/yaml/parsers-section.md#standalone-parsers-files). You can include one or more files. | _none_ |
+| `plugins_file` | Path for a `plugins` configuration file. This file specifies the paths to custom plugins (.so files) that Fluent Bit can load at runtime. Plugins can be declared directly in the [`plugins` section](../administration/configuring-fluent-bit/yaml/plugins-section.md) of YAML configuration files. | _none_ |
+| `streams_file` | Path for the [stream processor](../stream-processing/overview.md) configuration file. This file defines the rules and operations for stream processing in Fluent Bit. Stream processor configurations can also be defined directly in the `streams` section of YAML configuration files. | _none_ |
 | `http_server` | Enables the built-in HTTP server. | `off` |
 | `http_listen` | Sets the listening interface for the HTTP Server when it's enabled. | `0.0.0.0` |
 | `http_port` | Sets the TCP port for the HTTP server. | `2020` |
@@ -28,7 +27,7 @@ The `service` section defines global properties of the service. The available co
 
 ## Storage configuration
 
-The following storage-related keys can be set in the `service` section:
+The following storage-related keys can be set as children to the `storage` key:
 
 | Key | Description | Default Value |
 | --- | ----------- | ------------- |
diff --git a/pipeline/parsers.md b/pipeline/parsers.md
index 117cd18b9..e1f8314ec 100644
--- a/pipeline/parsers.md
+++ b/pipeline/parsers.md
@@ -1,8 +1,6 @@
 # Parsers
 
-Dealing with raw strings or unstructured messages is difficult. Having a structure makes data more usable. Set a structure for the incoming data by using input plugins as data is collected.
-
-Parsers are fully configurable and are independently and optionally handled by each input plugin.
+You can use parsers to transform unstructured log entries into structured log entries.
 
 ```mermaid
 graph LR
@@ -18,15 +16,15 @@ graph LR
     style B stroke:darkred,stroke-width:2px;
 ```
 
-The parser converts unstructured data to structured data. As an example, consider the following Apache (HTTP Server) log entry:
+For example, a parser can turn an unstructured log entry like this:
 
 ```text
 192.168.2.20 - - [28/Jul/2006:10:27:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395
 ```
 
-This log line is a raw string without format. Structuring the log makes it easier to process the data later. If the [regular expression parser](./parsers/regular-expression.md) is used, the log entry could be converted to:
+...into a structured JSON object like this:
 
-```javascript
+```json
 {
   "host":    "192.168.2.20",
   "user":    "-",
@@ -38,3 +36,44 @@ This log line is a raw string without format. Structuring the log makes it easie
   "agent":   ""
  }
 ```
+
+## How parsers work
+
+Parsers modify the data ingested by input plugins. This modification happens before Fluent Bit applies any [filters](../pipeline/filters.md) or [processors](..pipeline/processors.md) to that data.
+
+Each input plugin can have one active parser. Multiple plugins within the same Fluent Bit configuration file can use the same parser or use different parsers from each other.
+
+### Default parsers and custom parsers
+
+Fluent Bit includes a variety of [default parsers](https://github.com/fluent/fluent-bit/blob/master/conf/parsers.conf) for parsing common data formats, like Apache and Docker logs. You can also [define custom parsers](../configuring-fluent-bit/yaml/parsers-section.md).
+
+## Add a parser to an input plugin
+
+To add a parser to an input plugin, follow these steps.
+
+1. Either identify the name of the [default parser](https://github.com/fluent/fluent-bit/blob/master/conf/parsers.conf) you want to use, or [define a custom parser](../configuring-fluent-bit/yaml/parsers-section.md) with your desired [configuration settings](../pipeline/parsers/configuring-parser.md).
+
+1. Add a `parsers` key to the plugin's settings in the [`inputs`](../administration/configuring-fluent-bit/yaml/pipeline-section.md#inputs) section of your YAML configuration file.
+
+For example, the following configuration file adds the default [`apache` parser](https://github.com/fluent/fluent-bit/blob/master/conf/parsers.conf#L2) to one input plugin and a custom parser named `custom_parser1` to another input plugin:
+
+
+{% tabs %}
+{% tab title="fluent-bit.yaml" %}
+
+```yaml
+pipeline:
+  inputs:
+    - name: tail
+      path: /input/input.log
+      refresh_interval: 1
+      parser: apache
+
+    - name: http
+      listen: 0.0.0.0
+      port: 8888
+      parser: custom_parser1
+```
+
+{% endtab %}
+{% endtabs %}
diff --git a/pipeline/parsers/configuring-parser.md b/pipeline/parsers/configuring-parser.md
index 3d7cdb124..f88eac991 100644
--- a/pipeline/parsers/configuring-parser.md
+++ b/pipeline/parsers/configuring-parser.md
@@ -1,31 +1,16 @@
-# Configuring parsers
+# Configuring custom parsers
 
-You can use parsers to transform unstructured log entries into structured log entries, which makes it easier to process and further filter those logs.
-
-The parser engine is fully configurable and can process log entries based in two formats:
-
-- [JSON maps](json.md)
-- [Regular expressions](regular-expression.md) (named capture)
-
-By default, Fluent Bit provides a set of pre-configured parsers that can be used for different use cases, such as logs from:
-
-- Apache
-- NGINX
-- Docker
-- Syslog rfc5424
-- Syslog rfc3164
-
-Parsers are defined in configuration files that are loaded at start time, either through the main Fluent Bit configuration file (YAML or classic) or by using one or more external configuration files. You can also load parsers from the command line.
+Use the information on this page to configure custom [parsers](../pipeline/parsers).
 
 {% hint style="info" %}
 
-Fluent Bit uses Ruby-based regular expressions. You can use [Rubular](http://www.rubular.com) to test your regular expressions for Ruby compatibility.
+To define a custom parser, add an entry to the [`parsers` section](../configuring-fluent-bit/yaml/parsers-section.md) of your YAML configuration file, or create a [standalone parser file](../administration/configuring-fluent-bit/yaml/parsers-section.md#standalone-parsers-files).
 
 {% endhint %}
 
 ## Configuration parameters
 
-Multiple parsers can be defined and each section has it own properties. The following table describes the available options for each parser definition:
+Custom parsers support the following configuration parameters:
 
 | Key | Description |
 | --- | ----------- |
@@ -43,57 +28,7 @@ Multiple parsers can be defined and each section has it own properties. The foll
 | `Skip_Empty_Values` | Specifies a boolean which determines if the parser should skip empty values. The default is `true`. |
 | `Time_Strict` | The default value (`true`) tells the parser to be strict with the expected time format. With this option set to false, the parser will be permissive with the format of the time. You can use this when the format expects time fraction but the time to be parsed doesn't include it.  |
 
-## Parsers configuration file
-
-All parsers can be defined in a parsers file. The parsers file exposes all parsers available that can be used by the input plugins that are aware of this feature. A parsers file can have multiple entries, like so:
-
-{% tabs %}
-{% tab title="parsers.yaml" %}
-
-```yaml
-parsers:
-  - name: docker
-    format: json
-    time_key: time
-    time_format: '%Y-%m-%dT%H:%M:%S.%L'
-    time_keep: on
-
-  - name: syslog-rfc5424
-    format: regex
-    regex: '^\<(?<pri>[0-9]{1,5})\>1 (?<time>[^ ]+) (?<host>[^ ]+) (?<ident>[^ ]+) (?<pid>[-0-9]+) (?<msgid>[^ ]+) (?<extradata>(\[(.*)\]|-)) (?<message>.+)$'
-    time_key: time
-    time_format: '%Y-%m-%dT%H:%M:%S.%L'
-    time_keep: on
-    types: pid:integer
-```
-
-{% endtab %}
-{% tab title="parsers.conf" %}
-
-```text
-[PARSER]
-  Name        docker
-  Format      json
-  Time_Key    time
-  Time_Format %Y-%m-%dT%H:%M:%S.%L
-  Time_Keep   On
-
-[PARSER]
-  Name        syslog-rfc5424
-  Format      regex
-  Regex       ^\<(?<pri>[0-9]{1,5})\>1 (?<time>[^ ]+) (?<host>[^ ]+) (?<ident>[^ ]+) (?<pid>[-0-9]+) (?<msgid>[^ ]+) (?<extradata>(\[(.*)\]|-)) (?<message>.+)$
-  Time_Key    time
-  Time_Format %Y-%m-%dT%H:%M:%S.%L
-  Time_Keep   On
-  Types pid:integer
-```
-
-{% endtab %}
-{% endtabs %}
-
-For more information about the parsers available, refer to the [default parsers file](https://github.com/fluent/fluent-bit/blob/master/conf/parsers.conf) distributed with Fluent Bit source code.
-
-## Time resolution and fractional seconds
+### Time resolution and fractional seconds
 
 Time resolution and its format supported are handled by using the [strftime\(3\)](http://man7.org/linux/man-pages/man3/strftime.3.html) `libc` system function.
 
@@ -105,11 +40,11 @@ The option `%L` is only valid when used after seconds (`%S`) or seconds since th
 
 {% endhint %}
 
-## Supported time zone abbreviations
+### Supported time zone abbreviations
 
 The following time zone abbreviations are supported.
 
-### Universal time zones
+#### Universal time zones
 
 | Abbreviation | UTC Offset (`HH:MM`) | Offset (seconds) | Is DST | Description                |
 | ------------ | -------------------- | ---------------- | ------ | -------------------------- |
@@ -120,7 +55,7 @@ The following time zone abbreviations are supported.
 
 <!-- vale FluentBit.Headings = NO -->
 
-### North American time zones
+#### North American time zones
 
 | Abbreviation | UTC Offset (`HH:MM`) | Offset (seconds) | Is DST | Description                                              |
 | ------------ | -------------------- | ---------------- | ------ | -------------------------------------------------------- |
@@ -141,7 +76,7 @@ The following time zone abbreviations are supported.
 | `NST`        | `-03:30`             | `-12600`         | no     | Newfoundland Standard Time                               |
 | `NDT`        | `-02:30`             | `-9000`          | yes    | Newfoundland Daylight Time                               |
 
-### European time zones
+#### European time zones
 
 | Abbreviation | UTC Offset (`HH:MM`) | Offset (seconds) | Is DST | Description                      |
 | ------------ | -------------------- | ---------------- | ------ | -------------------------------- |
@@ -153,7 +88,7 @@ The following time zone abbreviations are supported.
 | `EEST`       | `+03:00`             | `10800`          | yes    | Eastern European Summer Time     |
 | `MSK`        | `+03:00`             | `10800`          | no     | Moscow Standard Time             |
 
-### South American time zones
+#### South American time zones
 
 <!-- vale FluentBit.Headings = YES -->
 
@@ -165,7 +100,7 @@ The following time zone abbreviations are supported.
 | `CLT`        | `-04:00`             | `-14400`         | no     | Chile Standard Time                                                      |
 | `CLST`       | `-03:00`             | `-10800`         | yes    | Chile Summer Time                                                        |
 
-### Australasian and Oceania time zones
+#### Australasian and Oceania time zones
 
 | Abbreviation | UTC Offset (`HH:MM`) | Offset (seconds) | Is DST | Description                        |
 | ------------ | -------------------- | ---------------- | ------ | ---------------------------------- |
@@ -177,7 +112,7 @@ The following time zone abbreviations are supported.
 | `NZST`       | `+12:00`             | `43200`          | no     | New Zealand Standard Time          |
 | `NZDT`       | `+13:00`             | `46800`          | yes    | New Zealand Daylight Time          |
 
-### Asian time zones
+#### Asian time zones
 
 | Abbreviation | UTC Offset (`HH:MM`) | Offset (seconds) | Is DST | Description                                               |
 | ------------ | -------------------- | ---------------- | ------ | --------------------------------------------------------- |
@@ -194,7 +129,7 @@ The following time zone abbreviations are supported.
 | `BDT`        | `+06:00`             | `21600`          | no     | Bangladesh Standard Time                                  |
 | `NPT`        | `+05:45`             | `20700`          | no     | Nepal Time                                                |
 
-### African time zones
+#### African time zones
 
 | Abbreviation | UTC Offset (`HH:MM`) | Offset (seconds) | Is DST | Description                 |
 | ------------ | -------------------- | ---------------- | ------ | --------------------------- |
@@ -203,7 +138,7 @@ The following time zone abbreviations are supported.
 | `EAT`        | `+03:00`             | `10800`          | no     | East Africa Time            |
 | `SAST`       | `+02:00`             | `7200`           | no     | South Africa Standard Time  |
 
-### Military time zones
+#### Military time zones
 
 {% hint style="info" %}
 
diff --git a/pipeline/parsers/decoders.md b/pipeline/parsers/decoders.md
index 21f4c401b..f367b8b1c 100644
--- a/pipeline/parsers/decoders.md
+++ b/pipeline/parsers/decoders.md
@@ -1,4 +1,4 @@
-# Decoders
+# Decoder settings
 
 There are cases where the log messages you want to parse contain encoded data. A typical use case can be found in containerized environments with Docker. Docker logs its data in JSON format, which uses escaped strings.
 
@@ -176,4 +176,4 @@ parsers:
 ```
 
 {% endtab %}
-{% endtabs %}
\ No newline at end of file
+{% endtabs %}
diff --git a/pipeline/parsers/json.md b/pipeline/parsers/json.md
index a8c86a721..bf80d9442 100644
--- a/pipeline/parsers/json.md
+++ b/pipeline/parsers/json.md
@@ -1,6 +1,6 @@
-# JSON
+# JSON format
 
-The _JSON_ parser transforms JSON logs by converting them to internal binary representations.
+Use the _JSON_ parser format to create custom parsers compatible with JSON data. This format transforms JSON logs by converting them to internal binary representations.
 
 For example, the default parsers configuration file includes a parser for parsing Docker logs (when the Tail input plugin is used):
 
@@ -41,4 +41,4 @@ After processing, its internal representation will be:
 [1154103724, {"key1"=>12345, "key2"=>"abc"}]
 ```
 
-The time was converted to a UTC timestamp and the map was reduced to each component of the original message.
\ No newline at end of file
+The time was converted to a UTC timestamp and the map was reduced to each component of the original message.
diff --git a/pipeline/parsers/logfmt.md b/pipeline/parsers/logfmt.md
index ba3ee79ac..d48485c21 100644
--- a/pipeline/parsers/logfmt.md
+++ b/pipeline/parsers/logfmt.md
@@ -1,8 +1,8 @@
-# Logfmt
+# Logfmt format
 
-The _logfmt_ parser lets you parse data in the [logfmt](https://pkg.go.dev/github.com/kr/logfmt?utm_source=godoc) format.
+Use the _logfmt_ parser format to create custom parsers compatible with [logfmt](https://pkg.go.dev/github.com/kr/logfmt?utm_source=godoc) data.
 
-Here is an example parsers configuration:
+The following example shows a custom parser that uses the `logfmt` format:
 
 {% tabs %}
 {% tab title="parsers.yaml" %}
@@ -62,4 +62,4 @@ parsers:
 ```
 
 {% endtab %}
-{% endtabs %}
\ No newline at end of file
+{% endtabs %}
diff --git a/pipeline/parsers/ltsv.md b/pipeline/parsers/ltsv.md
index 1ed3cd0c2..d5823629c 100644
--- a/pipeline/parsers/ltsv.md
+++ b/pipeline/parsers/ltsv.md
@@ -1,6 +1,6 @@
-# LTSV
+# LTSV format
 
-The _LTSV_ parser lets you parse data in the [Labeled Tab-separated Values (LTSV)](http://ltsv.org/) format.
+Use the _LTSV_ parser format to create custom parsers compatible with [Labeled Tab-separated Values (LTSV)](http://ltsv.org/) data.
 
 LTSV is a variant of the Tab-separated Values (TSV) format. Each record in an LTSV file is represented as a single line. Each field is separated by a tab and has a label and a value. The label and its value are separated by a colon (`:`).
 
@@ -13,7 +13,7 @@ LogFormat "host:%h\tident:%l\tuser:%u\ttime:%t\treq:%r\tstatus:%>s\tsize:%b\tref
 CustomLog "logs/access_log" combined_ltsv
 ```
 
-The following is an example parsers configuration file:
+The following example shows a custom parser that uses the `ltsv` format:
 
 {% tabs %}
 {% tab title="parsers.yaml" %}
@@ -64,4 +64,4 @@ After processing, its internal representation will be:
 ...
 ```
 
-The time was converted to Unix timestamp (UTC).
\ No newline at end of file
+The time was converted to Unix timestamp (UTC).
diff --git a/pipeline/parsers/regular-expression.md b/pipeline/parsers/regular-expression.md
index 0d33edaec..a58271945 100644
--- a/pipeline/parsers/regular-expression.md
+++ b/pipeline/parsers/regular-expression.md
@@ -1,6 +1,6 @@
-# Regular expression
+# Regular expression format
 
-The _Regular expression_ parser lets you define a custom Ruby regular expression that uses named capture to define which content belongs to which key name.
+Use the _regular expression_ parser format to create custom parsers with Ruby regular expressions. These regular expressions use named capture to define which content belongs to which key name.
 
 Use [Tail multiline](../inputs/tail.md#multiline) when you need to support regular expressions across multiple lines from a `tail`. The Tail input plugin treats each line as a separate entity.
 
@@ -74,4 +74,4 @@ This log entry doesn't provide a defined structure for Fluent Bit. Enabling the
               "agent"=>""
               }
 ]
-```
\ No newline at end of file
+```