diff --git a/doc/internals/filters.txt b/doc/internals/filters.txt
index cd3988f..5e9b58e 100644
--- a/doc/internals/filters.txt
+++ b/doc/internals/filters.txt
@@ -54,7 +54,7 @@
 be involved in the data processing, from the stream creation/destruction to
 the data forwarding. Depending of what it should do, a filter can implement all
 or part of these callbacks. For now, existing callbacks are focused on
-streams. But futur improvements could enlarge filters scope. For example, it
+streams. But future improvements could enlarge filters scope. For example, it
 could be useful to handle events at the connection level.
 
 In HAProxy configuration file, a filter is declared in a proxy section, except
@@ -84,7 +84,7 @@
 processing is serialized, each filter will bahave as it was alone (unless it was
 developed to be aware of other filters). For all that, some constraints are
 imposed to filters, especially when data exchanged between the client and the
-server are processed. We will dicuss again these constraints when we will tackle
+server are processed. We will discuss again these constraints when we will tackle
 the subject of writing a filter.
 
 
@@ -122,11 +122,11 @@
 Multiple filter lines can be used in a proxy section to chain filters. Filters
 will be called in the declaration order.
 
-Some filters can support implicit declarartions in certain circumstances
+Some filters can support implicit declarations in certain circumstances
 (without the filter line). This is not recommended for new features but are
 useful for existing ones moved in a filter, for backward compatibility
-reasons. Implicit declarartions are supported when there is only one filter used
-on a proxy. When several filters are used, explicit declarartions are mandatory.
+reasons. Implicit declarations are supported when there is only one filter used
+on a proxy. When several filters are used, explicit declarations are mandatory.
 The HTTP compression filter is one of these filters. Alone, using 'compression'
 keywords is enough to use it. But when at least a second filter is used, a
 filter line must be added.
@@ -283,7 +283,7 @@
 instances attached to a stream:
 
     /*
-     * Structure reprensenting the "global" state of filters attached to a
+     * Structure representing the "global" state of filters attached to a
      * stream.
      */
     struct strm_flt {
@@ -302,7 +302,7 @@
 'strm_flt.filters', each instance is of type 'struct filter *':
 
     /*
-     * Structure reprensenting a filter instance attached to a stream
+     * Structure representing a filter instance attached to a stream
      *
      * 2D-Array fields are used to store info per channel. The first index
      * stands for the request channel, and the second one for the response
@@ -659,7 +659,7 @@
 The main purpose of filters is to take part in the channels analyzing. To do so,
 there is 2 callbacks, 'flt_ops.channel_pre_analyze' and
 'flt_ops.channel_post_analyze', called respectively before and after each
-analyzer attached to a channel, execpt analyzers responsible for the data
+analyzer attached to a channel, except analyzers responsible for the data
 parsing/forwarding (TCP or HTTP data). Concretely, on the request channel, these
 callbacks could be called before following analyzers: