Arduino Nano ESP32 Pinout: GPIO, Dual Numbering Modes, and VBUS Explained

The Arduino Nano ESP32 is Arduino's own official answer to the question every ESP32 project eventually asks: why can't this run on an actual Arduino board? It's a genuine ESP32-S3 underneath -- WiFi, Bluetooth, native USB, all of it -- wrapped in the classic Nano form factor and pin layout Arduino users already know, with a pin numbering scheme designed to feel familiar rather than throwing raw GPIO numbers at you from the start.

That familiarity is also where the pinout gets genuinely different from a typical ESP32 board. Arduino gives this board its own default pin-numbering mode -- matching the classic Nano's D0-D13/A0-A7 layout -- alongside the option to fall back to raw ESP32-S3 GPIO numbers. Knowing which mode a piece of code assumes matters more here than on almost any other ESP32 board, and it's the single most common source of confusion for anyone coming to this board from a generic ESP32-S3 tutorial.

This guide covers the board's dual numbering systems, its full digital, analog, and communication pinout, and the power-pin design Arduino changed specifically because the ESP32-S3 underneath isn't 5V tolerant like classic Nano boards were.

Two Pin Numbering Systems

This is the single most important thing to understand about this board before wiring anything. Arduino IDE offers a choice: Nano form-factor numbering (the default -- D0, D1, A0, A1, and so on, matching older Nano boards) or GPIO numbering (the raw ESP32-S3 pin numbers used by most ESP32 tutorials and libraries).

pinMode(D2, OUTPUT);   // Nano-style numbering (default)
digitalWrite(D2, HIGH);

Code using pin labels like D2 or A0 works under either numbering mode, since those labels always point to the same physical pin regardless of the selected scheme. Code that references a bare integer (digitalWrite(14, HIGH)) means something different depending on which mode is active -- this single detail explains most "my ESP32 tutorial doesn't work on my Nano ESP32" reports, since most ESP32 example code assumes raw GPIO numbers.

Not Every Pin Is Physically Accessible

A handful of ESP32-S3 GPIOs referenced in some example code (GPIO15 for a chip-select line, for instance) aren't broken out on this board's physical header at all -- the Nano form factor simply doesn't have room for the S3's full pin count. Definitions at the top of a given code example typically flag which specific pins need manual reassignment for this reason. Since the underlying chip is the same ESP32-S3 covered in this site's full-size S3 pinout guide, its strapping pins (GPIO0, 3, 45, and 46) still apply the same way here, even though most of them aren't directly wired to the Nano's own labeled pins.

Digital, Analog, and PWM Pins

The board follows the classic Nano header layout: digital pins D0 through D13, and a separate analog header with A0 through A7. Every pin can function as a plain GPIO regardless of its default role, thanks to the ESP32-S3's pin flexibility underneath.

int reading = analogRead(A0);
analogWrite(D3, 128); // PWM, ~50% duty cycle

PWM works through the same software-mapped LEDC approach as any ESP32-S3 board -- not restricted to a fixed set of pins the way an AVR-based Nano's PWM is, even though the board deliberately presents itself with a classic-Nano-style layout.

No 5V Pin -- VBUS Instead

A genuinely unusual choice for a board wearing the Nano form factor: there is no 5V pin. In its place is VBUS, which only supplies 5V when the board is powered via USB. Powering the board through VIN instead disables VBUS entirely, meaning no 5V is available from the board at all in that scenario.

This is a deliberate safety measure -- the ESP32-S3 underneath runs 3.3V logic and isn't 5V tolerant, so Arduino chose to prevent accidental 5V exposure rather than risk it the way a traditional 5V-tolerant Nano could. A project relying on a steady 5V rail regardless of power source needs an external supply or a level shifter, not the board's own VBUS pin.

I2C, SPI, and UART

I2C: Default pins follow the classic Nano's SDA/SCL header position, though like any ESP32-S3 board, Wire.begin(sda, scl) can reassign to any free pin pair.

Wire.begin(); // uses the default SDA/SCL pins

SPI: The classic Nano SPI pin positions are wired through as expected, with the ESP32-S3's usual flexibility to remap if a project needs it.

UART: This is where the board's underlying ESP32-S3 shows through most clearly -- it has three separate serial ports. Serial is the USB connection to a computer. Serial0 is the first hardware UART, on the D0/D1 header pins. Serial1 and Serial2 are two additional hardware UARTs with no fixed default pins at all -- their TX and RX need to be manually assigned to any free GPIO before use.

Serial1.begin(9600, SERIAL_8N1, RX_PIN, TX_PIN);

That's one more usable UART than most ESP32 boards offer out of the box, and it means a project can run USB debugging, a GPS module, and a Bluetooth serial module simultaneously without any of them conflicting.

How the Nano ESP32 Compares

The Nano ESP32 is best understood as a translation layer -- the same ESP32-S3 capability as a generic devkit, presented through a header and numbering scheme built to feel like a drop-in Nano replacement rather than a new board to learn from scratch.

Power Pins

Every GPIO runs 3.3V logic -- treat this board like any other ESP32-S3 design for voltage purposes, not like a classic 5V-tolerant Nano, regardless of the familiar header layout.

Practical Pin Usage Tips

Pick one numbering mode and stay consistent within a project. Mixing Nano-style pin labels and raw GPIO integers in the same sketch is the single most common source of "wrong pin" bugs on this board.

Check example code for pins this board doesn't physically expose. Not every ESP32-S3 GPIO referenced in a generic tutorial reaches this board's header -- confirm against the Nano ESP32's own pinout diagram before assuming compatibility.

Don't assume a steady 5V rail is always available. VBUS disappears the moment power comes from VIN instead of USB -- plan power-hungry 5V peripherals around an external supply if the board won't always be USB-powered.

Take advantage of the three UARTs for multi-peripheral serial projects. It's an underused feature -- most ESP32 boards only offer two usable serial ports in practice.

Treat any classic Nano shield's voltage assumptions with caution. A shield physically fits, but anything expecting a genuine 5V rail or 5V-tolerant logic pins wasn't designed with this board in mind.

Summary: Nano ESP32 Pin Reference at a Glance

Arduino Nano ESP32 · ESP32-S3, dual-core Xtensa LX7 · WiFi 4 · BLE 5.0 · Classic Nano form factor · D0-D13 digital, A0-A7 analog · 3 hardware UARTs · No 5V pin — VBUS instead · Dual pin-numbering modes

Which Projects the Nano ESP32 Actually Fits

A strong fit: anyone with an existing Arduino Nano-based project or shield collection wanting to add real WiFi and Bluetooth without redesigning the physical layout, classroom or workshop settings where students already know the Nano form factor and Arduino IDE workflow, or any project that specifically wants three independent hardware UARTs in a small, familiar package.

A weaker fit: projects needing the ESP32-S3's full 45-pin GPIO budget (only a subset reaches this board's header), or anyone who's comfortable working with raw GPIO numbers and doesn't need the Nano-familiar numbering layer at all -- a generic ESP32-S3 devkit is simpler and cheaper in that case.

Migrating a Classic Nano Project

For anyone moving an existing ATmega328P-based Nano project over, the practical migration path is usually smoother than it first appears. Digital I/O, PWM, and analog reads translate directly once pin labels (D3, A0, and so on) are kept rather than bare integers. The places migrations most often stall are libraries written specifically for AVR hardware registers rather than the portable Arduino API -- anything directly manipulating PORTB or similar AVR-specific registers won't work on the ESP32-S3 at all and needs rewriting against the standard digitalWrite()/pinMode() calls instead. Timing-sensitive code written assuming the classic Nano's 16MHz clock also deserves a second look, since the ESP32-S3 runs its cores considerably faster and any hand-tuned delay loops (rather than proper delay()/millis() calls) will behave differently.

Quick Answers to Common Nano ESP32 Pin Questions

Why doesn't my ESP32 tutorial's pin numbers work on this board? It's almost certainly a numbering-mode mismatch -- most generic ESP32-S3 tutorials assume raw GPIO numbers, while this board defaults to Nano-style D/A labels. Switch numbering modes or convert the pin references.

Why is there no 5V pin? A deliberate safety choice -- the ESP32-S3 isn't 5V tolerant, so Arduino replaced the traditional 5V pin with VBUS, which only supplies 5V over USB and stays off entirely when powered via VIN.

How many serial ports does this board really have? Four total, counting USB: Serial (USB), Serial0 (D0/D1), and two more (Serial1, Serial2) that need their pins manually assigned before use.

Can I use classic Nano shields on this board? Physically the header matches, but check the specific shield's voltage assumptions -- anything expecting a true 5V pin won't find one here.

Is every ESP32-S3 GPIO available on this board? No -- the Nano form factor doesn't have room for the S3's full pin count, so some GPIOs referenced in generic ESP32-S3 example code simply aren't accessible here.

Does this board have the same strapping pins as a generic ESP32-S3 devkit? Yes -- GPIO0, 3, 45, and 46 remain the chip's strapping pins, though most aren't directly exposed on the Nano ESP32's own labeled header.

Where to Go From Here

Once the dual numbering modes and the VBUS-versus-5V distinction feel settled, the board's three hardware UARTs are worth building around next for any project juggling more than one serial peripheral at once -- something most classic Nano boards simply couldn't do. From there, since this is a genuine ESP32-S3 underneath, the rest of the ESP32-S3 ecosystem -- PSRAM-equipped variants, camera boards, native USB tricks -- carries over conceptually even though this specific board's header doesn't expose every one of those pins.