diff --git a/content/references/rippled-api/transaction-formats/transaction-common-fields.md b/content/references/rippled-api/transaction-formats/transaction-common-fields.md
index 80d0e71870..5e12440224 100644
--- a/content/references/rippled-api/transaction-formats/transaction-common-fields.md
+++ b/content/references/rippled-api/transaction-formats/transaction-common-fields.md
@@ -52,8 +52,14 @@ The [`Paths` field](payment.html#paths) of the [Payment transaction][] type can
 
 The `Flags` field can contain various options that affect how a transaction should behave. The options are represented as binary values that can be combined with bitwise-or operations to set multiple flags at once.
 
+To check whether a transaction has a given flag enabled, use the bitwise-and operator on the flag's value and the `Flags` field. A result of zero indicates the flag is disabled, and a result equal to the flag value indicates the flag is enabled. (Any other result indicates you performed the wrong operation.)
+
 Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the `TransactionType` field when setting and reading flags.
 
+Bits that are not defined as flags MUST be 0. (The [fix1543 amendment](known-amendments.html#fix1543) enforces this rule on some transaction types. Most transaction types enforce this rule by default.)
+
+### Global Flags
+
 The only flag that applies globally to all transactions is as follows:
 
 | Flag Name           | Hex Value  | Decimal Value | Description               |
@@ -64,6 +70,18 @@ When using the [sign method][] (or [submit method][] in "sign-and-submit" mode),
 
 **Warning:** If you do not enable `tfFullyCanonicalSig`, it is theoretically possible for a malicious actor to modify your transaction signature so that the transaction may succeed with a different hash than expected. In the worst case, this could trick your integration into submitting the same payment multiple times. To avoid this problem, enable the `tfFullyCanonicalSig` flag on all transactions you sign.
 
+### Flag Ranges
+
+A transaction's `Flags` field can contain flags that apply at different levels or contexts. Flags for each context are limited to the following ranges:
+
+| Range Name       | Bit Mask     | Description                                |
+|:-----------------|:-------------|:-------------------------------------------|
+| Universal Flags  | `0xff000000` | Flags that apply equally to all transaction types. |
+| Type-based Flags | `0x00ff0000` | Flags with different meanings depending on the [transaction type](transaction-types.html) that uses them. |
+| Reserved Flags   | `0x0000ffff` | Flags that are not currently defined. A transaction is only valid if these flags are disabled. |
+
+**Note:** The [AccountSet transaction][] type has [its own non-bitwise flags](accountset.html#accountset-flags), which serve a similar purpose to type-based flags. [Ledger objects](ledger-object-types.html) also have a `Flags` field with different bitwise flag definitions.
+
 
 ## Memos Field