3.3 V or 5 V
There is a 10 kΩ resistor on the board from VCC to DATA, and no way to remove it from outside. So whatever you feed the supply pin is what the signal wire idles at — which makes VCC the only wire on this board you can get wrong at a cost.
The resistor decides
Pick a supply and a board and watch what the data pin sees.
R1 goes from VCC to DATA. When nothing is pulling the wire down — which is most of the time, because the wire is idle between readings and the readings last milliseconds — the resistor holds DATA at the supply voltage. Exactly the supply voltage, with no divider and no series resistance anywhere.
So the supply pin is not a separate decision from the signal pin. They are the same decision.
The rule
| Your board | VCC goes to | Because |
|---|---|---|
| ESP32, ESP32-S3, Pico | 3V3 | pins are rated 3.3 V, and so is the idle data line |
| Arduino Uno, Nano | 5V | pins are 5 V tolerant and expect a 5 V high |
Both sensors work across both rails — the DHT11 from 3 to 5.5 V, the DHT22 from 3.3 to 6 V — so the sensor never constrains the choice. Your board does.
What goes wrong
Feed a sensor 5 V next to a 3.3 V processor and it works. It reads correctly, it answers every time, and there is nothing on screen to suggest anything is amiss. Meanwhile the input pin is sitting 1.7 V over its rating whenever the line is idle, which is nearly always.
ESP32 inputs have clamping diodes to the 3.3 V rail, so what actually happens is a small current flowing backwards into the rail through the pin, all day. Boards do survive it. They also fail months later for no visible reason, which is a worse outcome than a part that dies immediately and tells you why.
The fix is one wire moved: VCC to 3V3.
The other direction
The DHT22's minimum supply is 3.3 V exactly, with nothing to spare. On a board whose 3V3 rail dips during Wi-Fi transmits that is worth a moment's thought — a sag to 3.1 V is out of specification, and the failure mode is drifting numbers rather than a clean error.
The DHT11 has half a volt more room underneath it, from 3 V. If you have a marginal rail and a choice of sensor, that is a real point in the blue board's favour.
Neither sensor draws enough to matter: 1 to 2.5 mA while measuring, under 200 µA between readings, and both figures are inside anything a dev board's regulator can supply.
When it does not work
It usually does work, which is exactly the problem. The pull-up holds DATA at 5 V against a pin rated for 3.3 V, and the damage from that is cumulative rather than immediate — the board keeps working until one day it does not, and by then the cause is months old.
Not usefully. A series resistor into a CMOS input drops almost nothing, because almost no current flows. What works is either running the sensor from 3V3 — both sensors are happy there — or a proper bidirectional level converter in the data line if you need 5 V for some other reason.
The DHT22's minimum is 3.3 V with no margin underneath it, so a rail dipping to 3.1 V during a transmit burst is genuinely out of specification. A 100 µF across the sensor's supply pins helps; so does taking the reading between transmissions rather than during one.
No. About 1 to 2.5 mA while it is measuring and well under 200 µA the rest of the time, which any 3V3 regulator on any of these boards supplies without noticing. It is the voltage that matters here, never the current.
Two boards, two pins, one sketch, and the two numbers disagreeing in front of you.
Both sensors side by side →Edit this page — content/books/dht22/three-volts-or-five.mdx
Questions about this product
See what other owners have asked, and read their solutions.
This page covers several products. Choose yours to see the right discussions.
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.