{"title":"Raw Strings & Byte Strings","description":"","content":"Two string-adjacent literals trip up most Python beginners: `r\"...\"` and `b\"...\"`. Raw strings change how Python parses backslashes inside the literal, which makes them the right choice for Windows file paths, regex patterns, and JSON snippets that contain backslash sequences. Byte strings give you a `bytes` object instead of a `str`, which is what you actually need when reading binary files, talking to sockets, or feeding data into hashing libraries. This lesson covers both, including the quirks and the boundary where `str` and `bytes` meet.\n\n---\n\n# Why Raw Strings Exist\n\nInside a normal Python string literal, the backslash is special. It introduces an **escape sequence**: `\\n` becomes a newline, `\\t` becomes a tab, `\\\\` becomes a single backslash, and so on. That's useful most of the time, but it gets in the way when the text you actually want to store contains literal backslashes.\n\nTake a Windows-style file path for a product image:\n\n\n```python\npath = \"C:\\new_arrivals\\tablets\\report.txt\"\nprint(path)\n```\n\n\nThat output is not a typo. Python read `\\n`, `\\t`, and `\\r` as escape sequences. The string still contains the characters Python parsed, just not the ones you wrote. The first backslash followed by `n` became a newline, the second backslash followed by `t` became a tab, and so on. The path is destroyed before it ever reaches a function that opens the file.\n\nYou have two ways to fix this. The clumsy way is to double every backslash so Python parses each pair as a single literal backslash:\n\n\n```python\npath = \"C:\\\\new_arrivals\\\\tablets\\\\report.txt\"\nprint(path)\n```\n\n\nThat works, but for any path with more than a couple of backslashes, the doubled form is hard to read and easy to get wrong. The cleaner fix is the raw string prefix `r`:\n\n\n```python\npath = r\"C:\\new_arrivals\\tablets\\report.txt\"\nprint(path)\n```\n\n\nSame result, no doubled backslashes. The `r` in front of the opening quote tells Python: don't process escape sequences in this literal. Treat every backslash as a literal backslash character.\n\nThe same rule helps when you write a regex pattern. A pattern like `\\d+` (one or more digits) is much cleaner as `r\"\\d+\"` than as `\"\\\\d+\"`. Almost every regex example you see in Python code uses a raw string, and this is why.\n\nJSON snippets that contain escape sequences benefit too. If you're hand-writing a sample JSON string in Python source for a fixture or a test, raw strings keep the backslashes intact:\n\n\n```python\nsample_review = r'{\"product\": \"tablet\", \"comment\": \"Battery lasts 12+ hours\\nGreat for travel\"}'\nprint(sample_review)\n```\n\n\nThe `\\n` inside the JSON stays as the two characters `\\` and `n`, which is what JSON requires on the wire. Without the `r`, Python would have turned it into a real newline before the JSON parser ever saw it.\n\n---\n\n# Raw String Syntax and Quirks\n\nThe raw prefix is a single letter `r` (or `R`, both work) directly before the opening quote, with no space:\n\n\n```python\na = r\"plain raw\"\nb = r'single quotes too'\nc = r\"\"\"triple quotes work\"\"\"\nd = R\"capital R also works\"\n\nprint(a, b, c, d, sep=\" | \")\n```\n\n\nThe `r` only affects how the literal is parsed at compile time. Once Python finishes reading the source, the result is a normal `str` object. There is no separate \"raw string\" type. The string `r\"a\\n\"` and the string `\"a\\\\n\"` are the exact same `str` value: two characters, the letter `a` followed by a single backslash followed by the letter `n`.\n\n\n```python\nprint(r\"a\\n\" == \"a\\\\n\")\nprint(len(r\"a\\n\"))\nprint(type(r\"a\\n\"))\n```\n\n\nThree characters in both. Identical objects. Anything you can do to a normal string you can do to a raw string, because they are both just `str`. The raw prefix is purely a writing convenience.\n\nNow for the quirk that surprises everyone the first time. A raw string cannot end with an odd number of backslashes:\n\n\n```python\npath = r\"C:\\products\\images\\\"\n```\n\n\nThat's a real Python error, not a description. The closing quote looks like it should end the string, but Python's parser sees the backslash right before the quote and treats the pair `\\\"` as if it were trying to escape the quote, even inside a raw string. The literal is left unterminated.\n\nThe reason is subtle. Inside a raw string, `\\\"` is **not** an escape sequence in the normal sense. The string still contains both the backslash and the quote. But the tokenizer that decides where the literal ends still treats the backslash as preventing the next character from closing the literal. So you get a backslash and a quote inside the string, which means the literal hasn't ended, and the parser keeps looking for a closing quote that isn't there.\n\nYou'll only hit this when a raw string ends in a backslash, which is exactly the case for Windows directory paths. There are three reasonable workarounds:\n\n\n```python\n# Option 1: concatenate a non-raw literal with the trailing backslash\npath = r\"C:\\products\\images\" + \"\\\\\"\nprint(path)\n\n# Option 2: drop out of raw mode just for the last character\npath = r\"C:\\products\\images\" \"\\\\\"\nprint(path)\n\n# Option 3: write the whole thing without the r prefix and double the backslashes\npath = \"C:\\\\products\\\\images\\\\\"\nprint(path)\n```\n\n\nOption 1 is the most explicit. Option 2 uses Python's automatic string concatenation of adjacent literals. Option 3 abandons the raw form and goes back to escape sequences. Pick whichever reads cleanest in context.\n\n\n> **INFO**\n>\n> **Cost:** Concatenation with `+` allocates a new string. For a one-line path constant this is irrelevant. Inside a tight loop building thousands of paths, prefer `os.path.join` or `pathlib.Path`, which use forward slashes internally and sidestep the whole issue.\n\n\nA second quirk: a raw string with an even number of trailing backslashes is fine, because the last backslash isn't paired with the closing quote.\n\n\n```python\nprint(r\"C:\\products\\images\\\\\")\nprint(len(r\"C:\\products\\images\\\\\"))\n```\n\n\nThe literal contains 20 characters, including both trailing backslashes. The parser saw the second-to-last backslash escape the third-to-last (in tokenizer terms only), then the last backslash standing alone, then the closing quote. No error.\n\n---\n\n# Combined Prefixes: Raw Plus Bytes\n\nPython lets you combine the raw prefix with the bytes prefix. Both `rb\"...\"` and `br\"...\"` produce a `bytes` object whose backslashes are not interpreted as escapes:\n\n\n```python\npattern = rb\"\\d+\"\nprint(pattern)\nprint(type(pattern))\nprint(len(pattern))\n```\n\n\nThree bytes: backslash, `d`, `+`. Notice that `print` shows the backslash doubled in its `repr` form, but the underlying object only contains one. This combined prefix is most useful when you're working with the `re` module's bytes-mode regex (matching against `bytes` data rather than `str`).\n\nThe two letters can appear in either order. There's no behavioral difference:\n\n\n```python\nprint(rb\"\\n\" == br\"\\n\")\n```\n\n\nStyle guides usually prefer `rb` for \"raw bytes\", which reads naturally left-to-right. Pick one form and stick with it within a codebase.\n\n---\n\n# What Bytes Are\n\nA `str` in Python holds **text**. A character. A unicode code point. The string `\"café\"` has four characters, regardless of how those characters are encoded into bytes for storage or transmission.\n\nA `bytes` object holds **raw binary data**. A sequence of integers, each between `0` and `255`. There is no notion of \"character\" here. A `bytes` object might happen to contain text encoded as UTF-8, or it might contain a JPEG image, or the contents of a database file. Python doesn't know and doesn't care.\n\n\n```python\ntext = \"hello\"\ndata = b\"hello\"\n\nprint(type(text))\nprint(type(data))\nprint(text == data)\n```\n\n\nSame letters when printed, but different types. They aren't equal because they're not even the same kind of thing. A `str` of length 5 is five characters. A `bytes` of length 5 is five integers between 0 and 255. Comparing them returns `False`, never raises an error.\n\nIndexing into a `bytes` object returns an integer, not a one-character `bytes`:\n\n\n```python\ndata = b\"hello\"\nprint(data[0])\nprint(data[1])\nprint(type(data[0]))\n```\n\n\n`104` is the ASCII code for the letter `h`. `101` is the code for `e`. This catches a lot of beginners, because indexing into a `str` returns a single-character `str`:\n\n\n```python\ntext = \"hello\"\nprint(text[0])\nprint(type(text[0]))\n```\n\n\nTwo different worlds. To get a one-byte slice instead of an integer when working with `bytes`, slice with a range:\n\n\n```python\ndata = b\"hello\"\nprint(data[0:1])\nprint(type(data[0:1]))\n```\n\n\nSlicing `bytes` always returns `bytes`. Indexing returns `int`. The same difference exists for iteration: looping over a `bytes` object yields integers, not single bytes.\n\n\n```python\nfor value in b\"abc\":\n print(value)\n```\n\n\nWhy does any of this matter for an e-commerce app? Most input and output in a real system is bytes. When you read a file in binary mode, you get `bytes`. When data arrives over a network socket, it's `bytes`. When you compute an MD5 hash of a customer email for a checksum, the hashing library wants `bytes`. The `str` type is what you use **after** decoding those bytes into text, or **before** encoding text out to bytes for transmission.\n\n\n```mermaid\nflowchart LR\n STR[str
text
code points]:::cyan -->|encode| BYTES[bytes
raw data
0-255 ints]:::orange\n BYTES -->|decode| STR2[str
text
code points]:::cyan\n\n BYTES --> IO[Files in binary mode
Sockets
Hashes
HTTP bodies]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe arrows in the middle are `str.encode()` and `bytes.decode()`. The point right now is that bytes sit between your text and the outside world, and you need a separate type to represent that boundary cleanly.\n\n\n> **INFO**\n>\n> **Cost:** Decoding bytes to a `str` allocates a new string and copies the data. For a 10 KB HTTP response body that runs a few microseconds. Doing it on every byte you read in a loop is wasteful. Decode once, after you have the full message.\n\n\n---\n\n# Bytes Literals and Methods\n\nA `bytes` literal looks like a string literal with a `b` prefix in front of the opening quote. The contents must be ASCII, because each character has to fit in one byte:\n\n\n```python\ngreeting = b\"hello\"\nempty = b\"\"\nsingle = b\"!\"\n\nprint(greeting, empty, single)\nprint(len(greeting))\n```\n\n\nIf you try to put a non-ASCII character directly inside a `bytes` literal, Python rejects it at parse time:\n\n\n```python\noops = b\"café\"\n```\n\n\nTo put a non-ASCII byte in there, write its hex value with `\\x`:\n\n\n```python\ngreeting = b\"caf\\xc3\\xa9\"\nprint(greeting)\nprint(len(greeting))\n```\n\n\n`\\xc3\\xa9` is the two-byte UTF-8 encoding of `é`. Five bytes total: `c`, `a`, `f`, `0xc3`, `0xa9`. Each `\\xNN` escape is a single byte specified as exactly two hex digits.\n\nThe familiar escape sequences from regular strings work in bytes literals too. `\\n` is one byte (the newline, value `10`). `\\t` is one byte (the tab, value `9`). `\\\\` is one byte (a literal backslash):\n\n\n```python\ndata = b\"line1\\nline2\\tcol2\"\nprint(data)\nprint(len(data))\n```\n\n\nSeventeen bytes: five letters of `line1`, one byte for `\\n`, five letters of `line2`, one byte for `\\t`, four letters of `col2`. The `repr` shows the escapes back to you in their two-character form, but the underlying object holds the actual byte values.\n\n`bytes` objects support most of the methods you already know from `str`. They just operate on bytes instead of characters:\n\n\n```python\ndata = b\" Discounted Tablet \"\n\nprint(data.strip())\nprint(data.lower())\nprint(data.replace(b\"Tablet\", b\"Phone\"))\nprint(data.startswith(b\" Discount\"))\nprint(data.split(b\" \"))\n```\n\n\nThe catch is that the arguments must be `bytes`, not `str`. Mixing the two raises a `TypeError`:\n\n\n```python\ndata = b\"Discounted Tablet\"\nprint(data.replace(\"Tablet\", \"Phone\"))\n```\n\n\nThat `TypeError: a bytes-like object is required` is one of the most common errors when working with bytes. Anywhere a `bytes` method or function expects byte data, you have to give it byte data. Wrapping the `str` argument with `b\"...\"` (if it's a literal) or `.encode()` (if it's a variable) fixes it.\n\nHere are the most useful overlapping methods. The behavior matches the `str` versions you've already seen:\n\n\n| Method | Returns | Example |\n| --- | --- | --- |\n| `.upper()` / `.lower()` | New `bytes` | `b\"Hello\".upper()` is `b'HELLO'` |\n| `.strip()` | New `bytes` | `b\" hi \".strip()` is `b'hi'` |\n| `.startswith()` / `.endswith()` | `bool` | `b\"order_001\".startswith(b\"order_\")` is `True` |\n| `.split(sep)` | `list[bytes]` | `b\"a,b,c\".split(b\",\")` is `[b'a', b'b', b'c']` |\n| `.replace(old, new)` | New `bytes` | `b\"abc\".replace(b\"b\", b\"X\")` is `b'aXc'` |\n| `.find(sub)` | `int` (index or `-1`) | `b\"hello\".find(b\"ll\")` is `2` |\n\n\nThe mental model is straightforward: every text method that returns text also exists for bytes and returns bytes. The two type universes stay separate.\n\nA `bytes` object is **immutable**, just like a `str`. Once you create it, you can't modify the bytes inside. Methods like `.replace()` always return a new `bytes`:\n\n\n```python\ndata = b\"hello\"\ndata.replace(b\"h\", b\"H\")\nprint(data)\n```\n\n\nThe original is unchanged because `.replace()` returned a new object that we threw away. To keep the result, assign it back:\n\n\n```python\ndata = b\"hello\"\ndata = data.replace(b\"h\", b\"H\")\nprint(data)\n```\n\n\n\n> **INFO**\n>\n> **Cost:** Each call to `.replace()`, `.upper()`, `.strip()`, etc. allocates a new `bytes` object. Chaining many calls in a hot loop allocates each intermediate. If you're doing heavy in-place edits on a buffer, use `bytearray` instead.\n\n\n---\n\n# bytearray: The Mutable Cousin\n\n`bytes` is immutable. Sometimes you need to build a buffer one chunk at a time, or modify bytes in place without allocating a new object every time. That's what `bytearray` is for. It's the mutable version of `bytes`.\n\nYou create one from a `bytes` literal, an iterable of integers, or a length:\n\n\n```python\nbuffer = bytearray(b\"order_42\")\nprint(buffer)\nprint(type(buffer))\n\nempty = bytearray(5)\nprint(empty)\n```\n\n\n`bytearray(5)` allocates five zero bytes. That's a common starting point when you need a fixed-size scratch buffer.\n\nUnlike `bytes`, you can change individual bytes by index. The value you assign must be an integer between 0 and 255:\n\n\n```python\nbuffer = bytearray(b\"order_42\")\nbuffer[0] = ord(\"O\")\nbuffer[5] = ord(\"-\")\nprint(buffer)\n```\n\n\n`ord(\"O\")` returns `79`, the integer value of the uppercase `O`. Assigning to `buffer[0]` overwrites the byte in place. No new object is allocated.\n\nYou can also append bytes, extend with another sequence, or delete a slice:\n\n\n```python\nbuffer = bytearray(b\"abc\")\nbuffer.append(0x44)\nprint(buffer)\n\nbuffer.extend(b\"EF\")\nprint(buffer)\n\ndel buffer[0]\nprint(buffer)\n```\n\n\n`bytearray` supports the same overlapping method set as `bytes` (`.upper()`, `.split()`, `.replace()`, etc.) plus the in-place mutations (`.append()`, `.extend()`, item assignment, `del`).\n\nWhen should you reach for `bytearray` over `bytes`? Three real cases come up most:\n\n1. You're building up a binary message piece by piece and want to avoid allocating a new `bytes` on every chunk.\n2. You're parsing a binary file and want to fix up a few bytes in place.\n3. You're calling a low-level API (a hashing library, a compression routine) that wants to write into a buffer you provide.\n\nFor everything else, prefer `bytes`. Immutable types are safer to share and easier to reason about.\n\n\n> **INFO**\n>\n> **Cost:** `bytearray` mutations like `buffer[0] = x` are O(1). Appending to a `bytearray` amortizes to O(1) the same way list append does. By contrast, `bytes_a + bytes_b` allocates a new `bytes` of size `len(a) + len(b)` on every concatenation, which is O(n) per call.\n\n\nA quick reference table for the three text-and-bytes types:\n\n\n| Type | Mutable? | Holds | Index returns | Create from |\n| --- | --- | --- | --- | --- |\n| `str` | No | Unicode code points (text) | One-character `str` | `\"text\"`, `\"\".join(...)`, `bytes.decode()` |\n| `bytes` | No | Integers 0-255 (raw data) | `int` | `b\"data\"`, `bytes(iterable)`, `str.encode()` |\n| `bytearray` | Yes | Integers 0-255 (raw data) | `int` | `bytearray(b\"data\")`, `bytearray(n)`, `bytearray(iterable)` |\n\n\nThe conversion paths are worth memorizing:\n\n\n```python\ntext = \"café\"\n\n# str -> bytes\nencoded = text.encode(\"utf-8\")\nprint(encoded)\n\n# bytes -> str\ndecoded = encoded.decode(\"utf-8\")\nprint(decoded)\n\n# bytes -> bytearray\nmutable = bytearray(encoded)\nprint(mutable)\n\n# bytearray -> bytes\nback = bytes(mutable)\nprint(back)\n```\n\n\n`encode` and `decode` cross the text-bytes boundary. `bytes(...)` and `bytearray(...)` flip mutability without changing the content.\n\n---\n\n# str vs bytes: The Boundary\n\nThe recurring source of confusion in Python text-and-binary code is forgetting which side of the boundary you're on. Most modern Python code keeps `str` everywhere internally and only crosses to `bytes` at the edges (file I/O, network calls, hashing). The rules of thumb are short:\n\n- If you're reading a text file, opening with `open(path, \"r\")` (the default) gives you `str`.\n- If you're reading a binary file, opening with `open(path, \"rb\")` gives you `bytes`.\n- Network data, the `requests` library's `.content`, and most hashing inputs are `bytes`.\n- Anything you display to a human, log, or store as text is `str`.\n\nThe two cross with `.encode()` and `.decode()`:\n\n\n```python\ncustomer_email = \"anna@example.com\"\n\n# Going to bytes for hashing or transmission\nas_bytes = customer_email.encode(\"utf-8\")\nprint(as_bytes)\n\n# Coming back to text after reading from a binary source\nrestored = as_bytes.decode(\"utf-8\")\nprint(restored)\nprint(restored == customer_email)\n```\n\n\nFor ASCII text like email addresses or order IDs, the encoded and decoded forms look identical when printed. The difference shows up the moment you have a non-ASCII character or look at the type:\n\n\n```python\nprint(type(as_bytes))\nprint(type(restored))\n```\n\n\nThe shape of a real e-commerce code path looks roughly like this:\n\n\n```mermaid\nflowchart LR\n NET[Bytes from
HTTP body]:::orange -->|.decode| TEXT[str:
JSON text]:::cyan\n TEXT -->|json.loads| OBJ[dict / list]:::green\n OBJ -->|business logic| OBJ2[dict / list]:::green\n OBJ2 -->|json.dumps| TEXT2[str:
JSON text]:::cyan\n TEXT2 -->|.encode| OUT[Bytes for
response]:::orange\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nBytes at the edges, text in the middle. Once you keep the boundary clear, the `TypeError: a bytes-like object is required` errors stop showing up.\n\nYou have enough now to recognize when you need bytes (the wire, the disk, hash functions) versus when you need text (everything you actually look at).","pageType":"python"}

Raw Strings & Byte Strings

Get Premium