diff --git a/src/design.md b/src/design.md
index 5d336b2..42e85f7 100644
--- a/src/design.md
+++ b/src/design.md
@@ -12,10 +12,10 @@ nearly the same.
 EROFS data is all arranged in **fixed-size blocks** (aka. block-aligned,
 typically 4 KiB) like many modern disk filesystems (e.g. ext4, xfs, btrfs, f2fs,
 etc.) to match the intrinsic characteristics of [block devices](https://en.wikipedia.org/wiki/Block_\(data_storage\)).
-This means the corresponding data can be *directly* parsed if you read a single
+This means the corresponding data can be *directly* parsed by reading a single
 filesystem block for __non-encoded data__ or (possibly) multiple consecutive blocks
-(called a single physical cluster) for __encoded data__, which is different
-from _archive formats or unaligned filesystems_ (e.g. `cramfs`, `romfs`, `squashfs`,
+(called a single physical cluster) for __encoded data__, which differs from
+_archive formats or unaligned filesystems_ (e.g. `cramfs`, `romfs`, `squashfs`,
 `affs`, and possibly more FUSE-based implementations.)
 
 ![Comparison between unaligned and block-aligned data](_static/aligned_io.svg)
@@ -66,8 +66,8 @@ the final blocks of physical clusters will not be fully filled with encoded
 data. Currently LZ4, LZMA (Linux 5.15+), DEFLATE (Linux 6.6+), and Zstandard
 (Linux 6.10+) algorithms natively support this mode.
 
-Fixed-size output compression generally has better compression ratios, especially
-on small physical clusters (e.g. 4 or 8 KiB) with about 5% additional space saved.
+Fixed-size output compression generally provides better compression ratios,
+especially on small physical clusters (e.g., 4 or 8 KiB), saving about 5% additional space.
 
 Note that **small compressed physical clusters** are quite important to
 end-to-end performance for memory-intensive workloads (that is exactly the EROFS
diff --git a/src/developers.md b/src/developers.md
index f8a60b2..68eff76 100644
--- a/src/developers.md
+++ b/src/developers.md
@@ -18,8 +18,7 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
 | master       | erofs-utils stable tree                             |     No  |
 
 ### Linux kernel source
-
-If you're interested in EROFS kernel development, it'd be much better to keep
+If you're interested in EROFS kernel development, it is recommended to keep
 your local code in sync with the latest [EROFS development repo](https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git):
 
 ```sh
@@ -39,7 +38,7 @@ EROFS has its own development mailing list hosted by [OzLabs](https://www.ozlabs
 You can [subscribe to the mailing list](https://lists.ozlabs.org/listinfo/linux-erofs)
 to receive the latest status of EROFS.
 
-When posting, it'd be much helpful to:
+When posting, it is helpful to:
 
  - Add an additional tag in the subject like `[PATCH]`, `[question]` or
 `[bug report]`, etc.;
diff --git a/src/faq.md b/src/faq.md
index 012c69e..77e8d9a 100644
--- a/src/faq.md
+++ b/src/faq.md
@@ -2,13 +2,11 @@
 
 ## Why are images packaged in EROFS larger than those with SquashFS?
 
-First of all, the initial target use cases of EROFS are _high-performance
-embedded scenarios, such as smartphones powered by Android_. Runtime
-performance is always the top priority for EROFS (or, systems and applications
-will be lagged), even if it means sacrificing some ultra-space savings to avoid
+The primary target use cases of EROFS are _high-performance embedded scenarios, such as Android-powered smartphones_.  Runtime
+performance is always the top priority for EROFS (otherwise, systems and applications may experience performance issues), even if it means sacrificing some ultra-space savings to avoid
 significant performance regressions against uncompressed approaches.
 
-However, EROFS has landed **several new on-disk features** to narrow the slight
+However, EROFS has introduced**several new on-disk features** to narrow the slight
 size difference with SquashFS or even outperform SquashFS. When comparing,
 please ensure the same configuration is used:
 
@@ -63,8 +61,8 @@ In addition, EROFS may produce larger images due to the following differences:
 Note that EROFS is still under active development. The features mentioned above
 are not top priorities at the moment due to limited development resources
 (anyway, SquashFS has been existed for over 20 years) and target use scenarios,
-but they will be considered in the future, and contributions are always welcome.
-Again, note that SquashFS doesn't always outperform EROFS in image size either.
+but they may be considered in the future, and contributions are always welcome.
+Note that SquashFS does not always outperform EROFS in terms of image size.
 EROFS images are often significantly smaller (while still offering better
 runtime performance) when compressing files in small compressed extent sizes
 (especially smaller than 32KiB).
diff --git a/src/features.md b/src/features.md
index 3069254..28a05e3 100644
--- a/src/features.md
+++ b/src/features.md
@@ -6,9 +6,9 @@ imagefs.md
 comparison/dedupe.md
 ```
 
-Note that it's just **an incomplete list** for the qualitative evaluation.
-The overall purpose of this is to show EROFS benefits compared to other
-in-kernel approaches when making technical decisions.
+Note that this is only an **incomplete list** for qualitative evaluation.
+The overall purpose is to highlight the benefits of EROFS compared to other
+in-kernel filesystems when making technical decisions.
 
 | Feature  (as of Linux 6.17)     | EROFS             | EXT4      | SquashFS      |
 | ------------------------------- | ----------------- | --------- | ------------- |