ADB Is Not Recognized As An Internal Or External Command | Quick Fix For Windows Users

What The “ADB Is Not Recognized As An Internal Or External Command” Error Means

The adb tool lets your computer talk to an Android phone or tablet from a terminal window. With adb working, you can install apps, record the screen, pull log files, and send shell commands without touching the device itself.

When Windows shows the adb is not recognized as an internal or external command error, it is saying that Command Prompt cannot see any adb.exe file in the folders listed in the PATH setting. The shell only searches folders in PATH, so if platform tools sit outside that list, adb never starts.

The old phrase internal or external command comes from classic Windows wording. It simply means “a program or script Windows knows how to launch.” So this message does not point at a broken phone or a broken Android project. It almost always points at a missing adb installation or a PATH configuration problem on your PC.

Most cases fall into three groups. Some users never installed platform tools at all. Others installed them, but into a folder that Windows never checks. A third group moved or deleted the original folder, so PATH now points to a dead location and adb.exe is gone.

Fixing Adb Not Recognized As An Internal Or External Command On Windows

Before you touch any PATH settings, check that adb actually exists on disk. The Android SDK from Android Studio and the standalone platform tools download both include an adb.exe file. Your first task is to track down that folder and confirm that the file is ready to run.

1. Search For Platform Tools — Open File Explorer and search your system drive for a folder named platform-tools, often inside an Android or AndroidSdk directory.
2. Confirm adb.exe — Open the platform-tools folder and check that adb.exe sits next to fastboot.exe and several DLL files rather than an empty directory.
3. Run From The Folder — Click inside the folder’s address bar, type cmd, press Enter, then run adb devices in the prompt that appears to see whether adb works there.

If adb runs correctly from inside that platform tools folder, the core problem is clear. Windows can reach adb when you open Command Prompt in the right folder, but the shell cannot reach it from any random working directory.

When the adb is not recognized as an internal or external command message still appears even inside platform tools, the download may be damaged or outdated. In that case, grab a fresh copy of platform tools from the official Android developer site, extract it into a clean folder, and repeat the quick checks above.

Check Your Android Sdk Platform Tools Installation

Many Windows machines end up with more than one Android SDK. Android Studio installs its own copy, older tools may leave extra folders behind, and some users unzip standalone packages into new locations every year. That can confuse PATH and lead to mixed adb versions.

It helps to choose one clean SDK and stick with that. By pointing PATH at a single platform-tools folder, you avoid strange clashes between old and new builds of adb.exe.

• Find The Active Sdk — In Android Studio, open Settings, search for SDK, and note the Android SDK Location field, which often points to C:\Users\YourName\AppData\Local\Android\Sdk.
• Check The Platform Tools Folder — Inside that SDK directory, open platform-tools and confirm that adb.exe exists with a recent modified date rather than a file from many years ago.
• Clean Up Old Copies — If you see extra platform-tools folders on other drives, archive or delete the ones you no longer use so they do not distract you during PATH setup.

Once you settle on one platform tools location, that folder becomes your single source of truth for adb. Every fix that follows will rely on that path, so it is worth spending a minute verifying that this folder is stable and easy to reach.

Add Platform Tools To The Windows Path Safely

After you know where adb.exe lives, the next step is teaching Windows to check that folder every time you type adb. Windows does this through the PATH setting, which holds a list of folders separated by semicolons. When you run a command, the shell walks through that list from top to bottom.

1. Open System Properties — Press Win + R, type sysdm.cpl, press Enter, then switch to the Advanced tab in the window that appears.
2. Open Variable Settings — Click the button near the bottom that opens variable settings for your account and the whole system.
3. Edit The User Path — Under User variables for your account, select Path and choose Edit so you change the list for your own profile instead of the global list.
4. Add Platform Tools Path — Click New and paste the full path to your platform-tools folder, such as C:\Users\YourName\AppData\Local\Android\Sdk\platform-tools.
5. Move The Entry Up — Use the Move Up button to place the new platform tools entry near the top so Windows checks it early.
6. Restart Terminals — Close every Command Prompt and PowerShell window, open a fresh one, then run adb version to confirm that Windows now finds adb correctly.

When this works, the adb is not recognized as an internal or external command warning disappears in new terminal sessions, and adb version prints a short version string. If you still see the same message, there may be a typo in the path or the change may have been made under a different login than the one you are using.

On some company laptops, variable settings are locked. In that case, you might not be able to write to PATH. You can still work with adb by using one of the lighter approaches in the next section, which keep changes local to your user profile or to a single folder.

Other Ways To Run ADB Without Path Changes

Not everyone wants to adjust system settings for one tool. In shared or managed setups, you may prefer a method that keeps adb usage inside a project folder or inside your own account while still avoiding the “adb is not recognized as an internal or external command” message.

• Create A Shortcut Script — In a folder that is already part of PATH, create a small adb.bat file that calls the full path to your real adb.exe, then run adb from that folder to confirm the shortcut works.
• Open A Terminal In Platform Tools — In File Explorer, open the platform-tools folder, click in the address bar, type cmd or powershell, and press Enter so every adb command runs directly against that folder.
• Use A PowerShell Profile — For advanced users, adding a line to a PowerShell profile that appends the platform-tools folder to PATH for that shell only keeps global settings untouched.

Each of these routes makes sure the current shell knows where adb.exe sits before you type any commands. They do not need full PATH edits, which can help when you work on machines that other people maintain.

When The Error Comes From Device Or Usb Issues

Sometimes the original “ADB Is Not Recognized As An Internal Or External Command” error goes away, yet adb devices still shows an empty list. In that case, adb itself works, but the phone never shows up. That is a separate layer of trouble, and it often comes down to simple cable or driver details.

This second group of problems can appear right after you fix the PATH setting, so it helps to tell the messages apart. The first message means Windows cannot find adb.exe. The second group of messages means adb.exe runs but cannot reach any Android device.

• Turn On Usb Debugging — On the Android device, open Developer options and turn on USB debugging so the phone accepts adb commands from a computer.
• Approve The Computer — When you plug in the device, unlock it and confirm the RSA fingerprint prompt so the phone trusts the machine you are using.
• Install Usb Drivers — On Windows, install the correct USB driver from the phone maker or the Google USB driver through the SDK Manager if adb devices shows no entries.
• Try Different Cables And Ports — Swap to a known data cable, try another USB port on the computer, and avoid unpowered hubs that may drop the link.

Once both layers work, adb runs cleanly in the terminal and your phone appears in the device list every time you connect. That combination gives stable adb sessions and far fewer surprises during builds or debugging work.

Quick Reference Fix Table For ADB Errors

The table below maps common adb messages to the most likely cause and a direct fix, so you can scan it quickly when something goes wrong.

With a stable platform-tools folder, a clean PATH entry, and basic USB habits in place, the adb is not recognized as an internal or external command warning turns into a one-time fix instead of a constant distraction whenever you open a terminal window.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback