Word to Megabyte

A word's size depends on the CPU architecture. In x86/x64 (Intel/AMD) documentation: word = 16 bits, DWORD = 32 bits, QWORD = 64 bits. In ARM 32-bit: word = 32 bits. In most modern 64-bit systems (excluding x86 documentation): word = 64 bits. When reading technical documentation, always check the architecture's definition, as "word" is not a universal fixed size.

In Windows API documentation and x86 architecture, a DWORD (Double Word) = 32 bits = 4 bytes, capable of holding values 0–4,294,967,295 (unsigned) or -2,147,483,648 to 2,147,483,647 (signed). DWORD is the most common fixed-width integer type in the Windows API, used for flags, handles, and return codes. The equivalent in modern C/C++ is uint32_t (unsigned) or int32_t (signed).

A CPU's word size determines: (1) the maximum addressable memory — a 32-bit CPU addresses up to 4 GiB (2³² bytes); a 64-bit CPU addresses up to 16 EiB (2⁶⁴ bytes); (2) the precision of integer arithmetic — a 64-bit word handles numbers up to ~18.4 × 10¹⁸ in a single instruction; (3) performance — operations on data smaller than the word size may require extra sign-extension instructions on some architectures.

Modern x86-64 CPUs (Intel Core, AMD Ryzen) have 64-bit general-purpose registers, so their native word size is 64 bits for most operations. However, x86 documentation maintains the legacy definition: "word" = 16 bits, DWORD = 32 bits, QWORD = 64 bits. This creates a confusing terminology mismatch between the architectural naming convention and the physical register size.

Memory alignment means storing data at addresses that are multiples of the data's size. A 32-bit word should be stored at an address divisible by 4 (bytes); a 64-bit word at an address divisible by 8. Misaligned access is either forbidden (causes a CPU fault) or penalised (requires two memory reads instead of one). Compilers automatically align variables; manual struct packing can create misalignment that causes subtle performance issues or crashes on strict architectures.

A JPEG photo from a modern smartphone is typically 3–8 MB depending on resolution and compression settings. A RAW format photo from a DSLR or mirrorless camera is 20–50 MB per shot. A PNG screenshot at full HD (1920×1080) is about 1–3 MB; a compressed JPEG screenshot may be under 200 kB.

Video data usage depends heavily on quality: SD video uses roughly 700 MB per hour; HD (1080p) uses 1.5–3 GB per hour; 4K uses 7–20 GB per hour. These are byte-based measurements. In terms of bitrate: SD ≈ 1.5 Mbps, HD ≈ 5–8 Mbps, 4K ≈ 15–25 Mbps — where the "b" is bits, requiring division by 8 to convert to MB/s.

Compression algorithms like ZIP, GZIP, and ZSTD find and eliminate redundancy in data. Typical ratios vary dramatically by file type: plain text compresses to 20–30% of original size (a 10 MB log file becomes 2–3 MB); source code compresses to 25–35%; office documents (DOCX, XLSX) are already ZIP-compressed internally, so re-compressing gains little. JPEG, MP3, and H.264 video are already lossy-compressed and typically shrink by less than 5% with ZIP. A 100 MB folder of mixed files typically compresses to 40–60 MB. The key principle: compression removes statistical redundancy, so already-compressed or random data cannot be reduced further.

MB (megabyte) = 1,000,000 bytes (SI decimal). MiB (mebibyte) = 1,048,576 bytes (IEC binary). The difference is about 4.9%. Windows historically displayed storage in binary units but labelled them as "MB" — confusingly. Since Windows Vista, Microsoft has used the binary calculation consistently. macOS switched to SI decimal units in OS X 10.6 Snow Leopard (2009), matching the way hard drive manufacturers measure capacity.

Approximate data consumption per hour: web browsing = 60–100 MB, social media scrolling = 100–300 MB, music streaming (Spotify standard) = 40–50 MB, video calls (Zoom standard quality) = 300–500 MB, YouTube HD = 1,500–3,000 MB. These are rough averages and vary by content, settings, and network conditions.