# Fix libphonenumber invalid region code error

## TL;DR

The region code must be an uppercase ISO 3166 two-letter code, so normalize it before parsing. Lowercase, three-letter, or full country names all fail validation. Uppercase the code and validate it against the ISO list, then parse.

## The error

```text
Error: Invalid region code: "usa"
libphonenumber parse rejects the region
```

## Fix it

### Step 1: Reproduce with the failing value

```bash
node -e "const {parsePhoneNumberFromString}=require('libphonenumber-js'); console.log(parsePhoneNumberFromString('+15551234567','usa'))"
```

Expected: You see the invalid region error or a null result.

### Step 2: Normalize to uppercase two-letter codes

```bash
node -e "const fix=r=>String(r).trim().toUpperCase().slice(0,2); console.log(fix('usa'), fix(' us '))"
```

Expected: usa becomes US, with a note that truncation is a stopgap not a mapping.

### Step 3: Map names to codes properly instead of truncating

```bash
node -e "console.log('keep a name to code map for inputs like united states to US, do not slice names')"
```

Expected: Real mapping replaces the hack.

### Step 4: Parse again and confirm

```bash
node -e "const {parsePhoneNumberFromString}=require('libphonenumber-js'); const p=parsePhoneNumberFromString('+15551234567','US'); console.log(p.isValid(), p.formatInternational())"
```

Expected: The number parses and validates.

## When to use this

- libphonenumber rejects the region code
- Region codes come from user input or a CMS

## When NOT to use this

- The region is valid but the number is invalid, check the number
- You parse without a region, pass one or use full international format

## Tool and version compatibility

- libphonenumber-js, google-libphonenumber
- ISO 3166-1 alpha-2 codes

## Variant phrasings

### region code with whitespace

Trim before validating. CMS values often carry stray spaces.

### three-letter codes in the data

Map alpha-3 to alpha-2 explicitly. Slicing gives the wrong code for many countries.

## Why it happens

The library validates the region against the ISO alpha-2 list before parsing. Anything else, lowercase, names, alpha-3, fails fast with the invalid region error instead of guessing.

## Edge cases

- Some territories share codes, know which one your data means
- Validate the region once at ingestion, not on every parse
- The error message quotes your input, read it, it usually shows the problem

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst__9t9epgKS38n7To6tuZhYw