diff --git a/README.md b/README.md
index 01dd29a..fe61e24 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
 # KaraDAV - A lightweight WebDAV server, compatible with ownCloud and NextCloud clients
 
-This is a simple and lighweight WebDAV server, allowing to easily set up a file sharing server compatible with WebDAV and NextCloud clients. It has no dependencies and good performance.
+This is a simple and lightweight WebDAV server, allowing to easily set up a file sharing server compatible with WebDAV and NextCloud clients. It has no dependencies and good performance.
 
 It is written in PHP (8+). The only dependency is SQLite3 for the database.
 
@@ -300,7 +300,7 @@ But they mostly pass with litmus 0.13-3 supplied by Debian:
 30. unlock................ pass
 31. prep_collection....... pass
 32. lock_collection....... pass
-33. owner_modify.......... FAIL (PROPPATCH on locked resouce on `/files/demo/litmus/lockcoll/lockme.txt': 423 Locked)
+33. owner_modify.......... FAIL (PROPPATCH on locked resource on `/files/demo/litmus/lockcoll/lockme.txt': 423 Locked)
 34. notowner_modify....... pass
 35. refresh............... pass
 36. indirect_refresh...... pass
diff --git a/doc/NEXTCLOUD.md b/doc/NEXTCLOUD.md
index 68bb40a..808458c 100644
--- a/doc/NEXTCLOUD.md
+++ b/doc/NEXTCLOUD.md
@@ -17,7 +17,7 @@ The first login API requires you to simply generate an app password and redirect
 2. You redirect or display a login form for the user (it is recommended that you ask the user to confirm that he wants to allow the app after login)
 3. After login you redirect to this special URL: `nc://login/server:https://...&user:bohwaz&password:supersecret`.
 
-Because why re-use standard URL query parameters when you can invent weird stuff, you have to use a colon instead of an equal sign. Also it seems that parameters cannot be URL-encoded, so not sure what happens if your server URL, username or password contain a special character. But aside from that it is quite straightforward.
+Because why reuse standard URL query parameters when you can invent weird stuff, you have to use a colon instead of an equal sign. Also it seems that parameters cannot be URL-encoded, so not sure what happens if your server URL, username or password contain a special character. But aside from that it is quite straightforward.
 
 The second API is different but is explained in the documentation, it involves extra steps. When the process finishes, the user is left to close the opened browser window, so you got to have a specific waiting page for that. The desktop app will try to request (poll) the username and password every time it receives focus again, or every 30 seconds.