Resize a binary value between 4, 8, 16, 32 and 64 bits. Widening sign-extends to preserve the value; narrowing warns you when truncation changes it.
Show calculation steps
Processed privately in your browser — nothing you paste is uploaded, logged or stored.
Resizing without lying
Changing a value’s bit width is safe in one direction and dangerous in the other. Widening preserves the value if done correctly — zeros extend unsigned values, copies of the sign bit extend signed ones. Narrowing simply discards high bits, and whether the value survives depends entirely on what those bits held.
This converter performs both directions explicitly, shows the extension bits, and — crucially — warns with before/after values when a truncation changed the number, the thing C casts do silently.
Worked example
Widen 10110110 (−74 signed) from 8 to 16 bits: sign-extend: 11111111 10110110 → still −74 ✓ zero-extend: 00000000 10110110 → +182 ✗ (value changed!) The signed toggle selects which behaviour you get.
MOVZX versus MOVSX
x86 encodes the distinction in its instruction set: MOVZX zero-extends, MOVSX sign-extends. Choosing wrongly is a classic assembly and FFI bug — a −1 byte becomes 255 across a careless boundary. Every such bug is this page’s worked example wearing production clothes.
Truncation honesty
Narrowing 8→4 bits keeps only the low nibble. 00000110 (6) survives; 10110110 does not — the tool reports the old and new values side by side. If your pipeline narrows values, the warning line is the test case you should encode.
Privacy
Resizing runs in-page; patterns are never transmitted.
How to use the Binary Bit Width Converter
- Enter the bit pattern and its current width.
- Choose the target width and whether the value is signed.
- Click "Resize width".
- Widening shows the sign-extension (or zero-fill); narrowing warns if the value changed.
Frequently asked questions
What is sign extension and why is it needed?
When widening a signed value, the new left bits must COPY the sign bit or the value changes: −74 as 10110110 widens to 16 bits as 11111111 10110110. Zero-filling instead would turn it into +182 – a classic porting bug.
When is zero extension correct instead?
For unsigned values – address fragments, counters, masks. The signed toggle exists because the right answer genuinely depends on what the bits mean, not on the bits themselves.
What happens when I narrow a value?
The high bits are discarded. If they were all sign copies (or zeros for unsigned), the value survives; otherwise it changes, and the tool warns with both before/after values – mirroring what a C cast does silently.
Why do CPUs have separate MOVZX and MOVSX instructions?
Exactly this distinction: x86 zero-extends with MOVZX and sign-extends with MOVSX. Using the wrong one is the assembly-level version of the porting bug above; the converter lets you preview both behaviours.
Which widths are supported?
4, 8, 16, 32 and 64 bits in both directions – covering nibbles, bytes, and the standard register sizes. The pattern is validated against the FROM width before anything else.
Does widening ever change a value?
Never, when the correct extension is used – that is the invariant the steps demonstrate. Narrowing is the only lossy direction.
Is the resizing computed locally?
Yes, entirely in-page – patterns are never sent anywhere.
