diff --git a/internals/content-encoding.md b/internals/content-encoding.md
index dfa89a6e02..f53c0c26b5 100644
--- a/internals/content-encoding.md
+++ b/internals/content-encoding.md
@@ -8,7 +8,7 @@
  schemes include `deflate` (the zlib algorithm), `gzip`, `br` (brotli) and
  `compress`. A client requests that the server perform an encoding by
  including an `Accept-Encoding` header in the request document. The value of
- the header should be one of the recognized tokens `deflate`, ... (there's a
+ the header should be one of the recognized tokens `deflate`, ... (there is a
  way to register new schemes/tokens, see sec 3.5 of the spec). A server MAY
  honor the client's encoding request. When a response is encoded, the server
  includes a `Content-Encoding` header in the response. The value of the
diff --git a/internals/structs.md b/internals/structs.md
index 14361c9c32..22b13c5db8 100644
--- a/internals/structs.md
+++ b/internals/structs.md
@@ -112,8 +112,8 @@ of date at times.
   Each unique protocol that is supported by libcurl needs to provide at least
   one `Curl_handler` struct. It defines what the protocol is called and what
   functions the main code should call to deal with protocol specific issues.
-  In general, there's a source file named `[protocol].c` in which there's a
-  `struct Curl_handler Curl_handler_[protocol]` declared. In `url.c` there's
+  In general, there is a source file named `[protocol].c` in which there is a
+  `struct Curl_handler Curl_handler_[protocol]` declared. In `url.c` there is
   then the main array with all individual `Curl_handler` structs pointed to
   from a single array which is scanned through when a URL is given to libcurl
   to work with.
diff --git a/internals/tests/file-format.md b/internals/tests/file-format.md
index 2f17e56c03..476968dfad 100644
--- a/internals/tests/file-format.md
+++ b/internals/tests/file-format.md
@@ -315,7 +315,7 @@ about to issue.
 
 - `REPLY [command] [return value] [response string]` - Changes how the server
   responds to the [command]. [response string] is evaluated as a perl string,
-  so it can contain embedded `\r\n`, for example. There's a special [command]
+  so it can contain embedded `\r\n`, for example. There is a special [command]
   named "welcome" (without quotes) which is the string sent immediately on
   connect as a welcome.
 - `REPLYLF` (like above but sends the response terminated with LF-only and not
@@ -502,7 +502,7 @@ that is returned. The last slash in the URL must be followed by a number. That
 number (N) will be used by the test-server to load test case N and return the
 data that is defined within the `<reply><data></data></reply>` section.
 
-If there's no test number found above, the HTTP test server will use the
+If there is no test number found above, the HTTP test server will use the
 number following the last dot in the given hostname (made so that a CONNECT
 can still pass on test number) so that "foo.bar.123" gets treated as test case
 123. Alternatively, if an IPv6 address is provided to CONNECT, the last
@@ -510,10 +510,10 @@ hexadecimal group in the address will be used as the test number! For example
 the address "[1234::ff]" would be treated as test case 255.
 
 Set `type="perl"` to write the test case as a perl script. It implies that
-there's no memory debugging and valgrind gets shut off for this test.
+there is no memory debugging and valgrind gets shut off for this test.
 
 Set `type="shell"` to write the test case as a shell script. It implies that
-there's no memory debugging and valgrind gets shut off for this test.
+there is no memory debugging and valgrind gets shut off for this test.
 
 Set `option="no-output"` to prevent the test script to slap on the `--output`
 argument that directs the output to a file. The `--output` is also not added