diff --git a/doc/source/user/multinode.rst b/doc/source/user/multinode.rst
index f051b5e87c..5ad33bc17f 100644
--- a/doc/source/user/multinode.rst
+++ b/doc/source/user/multinode.rst
@@ -209,7 +209,7 @@ to them:
 
 .. note::
 
-   RabbitMQ doesn’t work with IP addresses, hence the IP address of
+   RabbitMQ doesn't work with IP addresses, hence the IP address of
    ``api_interface`` should be resolvable by hostnames to make sure that all
    RabbitMQ Cluster hosts can resolve each others hostnames beforehand.
 
diff --git a/specs/logging-with-heka.rst b/specs/logging-with-heka.rst
index 17ba4b3eb9..7cd7770b31 100644
--- a/specs/logging-with-heka.rst
+++ b/specs/logging-with-heka.rst
@@ -62,7 +62,7 @@ run it on every node of the cluster. In contrast, Logstash runs in a JVM and
 is known [3] to be too heavy to run on every node.
 
 Another important aspect is flow control and avoiding the loss of log messages
-in case of overload. Heka’s filter and output plugins, and the Elasticsearch
+in case of overload. Heka's filter and output plugins, and the Elasticsearch
 output plugin in particular, support the use of a disk based message queue.
 This message queue allows plugins to reprocess messages from the queue when
 downstream servers (Elasticsearch) are down or cannot keep up with the data