ByteScope

Bitwise Calculator

AND, OR, XOR, shifts and a clickable bit grid — plus a bitfield decoder for the register in front of you.

Your files never leave your browser — all processing is local.

Value

Unsigned

0

Signed

0

Bit grid

Click a bit to flip it — every representation below updates.

MSBLSB

Operations

Bitwise

Shift & rotate

A

0x00

A is always the value above.

Result

Binary

0b0000_0000

Hex

0x00

Decimal

0

MSBLSB

Register bitfield viewer

Describe the layout once, decode the value above every time it changes.

name:width pairs, comma-separated, most-significant field first — widths must fit within the selected width.

Saved layouts

Saved in this browser only (localStorage) — clearing site data or switching browsers loses them.

No saved layouts yet.

About this tool

You have a datasheet open, a register reads 0x3F80, and the only question that matters is what each field says. Paste the value, describe the layout once — reserved:1, mode:3, prescaler:4, enable:1, status:7 — and every field comes back with its bit range, its raw binary, and its value in decimal and hex. Layouts are saved in your browser, so a register you typed in while reading page 412 of the reference manual is still there next week: the next time that value shows up in a log you decode it in two seconds instead of counting nibbles on paper.

The signed and unsigned readings sit next to each other rather than behind a toggle. 0xFF is 255 and −1 at the same time; which one is true depends entirely on how the code that produced it declared the variable, and reaching for the wrong one is a whole bug class — a sensor that reports −1 °C as 255, a status field that looks like an enormous count. Two columns at once turns that from a mistake you make into a question you answer: if unsigned says 65,535 and signed says −1, you already know what you are looking at.

Width is not decoration. 1 << 40 is 0 at 32 bits and 1,099,511,627,776 at 64; NOT 0x0F is 0xF0 in a byte and 0xFFFFFFF0 in a word; shifting a negative value right depends on how many bits it lives in. JavaScript's own <<, >> and & truncate every operand to 32 bits before they even start, which is why so many web calculators quietly get 64-bit answers wrong — 1 << 31 comes out negative and anything past 2^32 collapses to 0. This page does its arithmetic in BigInt and masks to the width you picked, so 64-bit results are exact and 8-bit results wrap the way a uint8_t really does.

Reading 0b0011_1111_1000_0000 off a screen and deciding whether bit 7 is set is exactly the kind of counting people get wrong at 2am, so there is a clickable bit grid: every bit is a labelled cell, clicking one flips it, and binary, decimal, hex, the signed and unsigned readings and the bitfield decode all update together. Everything runs in your browser on a static page with no API behind it, which matters here — register values from unreleased hardware are genuinely confidential, and the field names you invent while reverse-engineering a peripheral say as much about the chip as the numbers do.

Frequently asked questions

What is the difference between >> and >>>?

>> is an arithmetic shift: it preserves the sign bit by copying it into the bits that open up at the top, so -8 >> 1 is -4 and a negative number stays negative. >>> is a logical shift: it always fills with zeros, so the same pattern slides down and reads as a large positive number instead. For positive values the two are identical, which is why the difference only bites once the top bit is set. In C there is only one >> and the type decides — signed operands shift arithmetically, unsigned ones logically — so this page makes the width and the signedness explicit instead of leaving them implied.

Why is 1 << 31 negative in JavaScript but not here?

Because JavaScript's bitwise operators convert their operands to 32-bit signed integers first. 1 << 31 sets the top bit of a 32-bit signed value — the sign bit — so it prints as −2147483648, and one step further 1 << 32 is 1 again because the shift count is taken modulo 32. This calculator works in BigInt and applies your chosen width afterwards, so at 32-bit the unsigned column reads 2,147,483,648 with −2,147,483,648 beside it, and at 64-bit 1 << 40 is a real 1,099,511,627,776 instead of 0.

How do I write a field layout?

One name:width pair per field, separated by commas: status:4, error:1, reserved:3 describes an 8-bit register. Fields are listed from the most significant bit downward, the way datasheets draw them, and the widths have to add up to the register width you selected — the tool says so when you are short or over. Use reserved: for the gaps you do not care about; keeping them in the layout is what keeps the bit offsets of everything below them correct. Each saved layout has its own name, so CTRL1, STATUS and FIFO_CFG from the same chip can sit side by side.

Why show a signed and an unsigned reading instead of asking me to choose?

Because at the moment you paste a value you often do not know yet. A byte out of a serial dump is just eight bits; whether 0xFE means 254 or −2 is a property of the code that wrote it, not of the bits. Asking you to pick first means picking wrong some of the time and never noticing, because either reading looks plausible on its own. Shown together, 0xFE reads 254 and −2, and the one that matches the physical quantity is obvious — a byte count cannot be negative, a temperature can.

What does changing the bit width actually change?

It sets the mask every result is reduced to, and with it the position of the sign bit. At 8-bit, 0x1FF truncates to 0xFF, NOT 0 is 0xFF, and the signed reading turns negative from 0x80 up; at 64-bit the same operations keep all 64 bits and the sign bit is bit 63. Shifts change too, because bits pushed past the top are discarded rather than remembered — which is precisely what a uint16_t register does to them. Switch the width and every panel is recomputed at the new size: binary, hex, the bit grid and the bitfield decode.

Are my values or saved layouts uploaded anywhere?

No. The page is a static file, all the arithmetic happens in your browser, and saved field layouts live in your browser's localStorage, so they never leave the machine and there is no account to sign into. The trade-off is that they are per-browser and per-profile: clearing site data removes them, and a layout you defined on your laptop will not show up on your desktop. Keep a copy of any layout you would hate to retype from the datasheet.