Introduction

MySQL Workbench can query tables that contain BLOB columns, but it usually does not render the binary contents inline in the result grid. Instead, you either open the cell in the built-in value viewer or transform the binary data into a readable representation with SQL.

Why Workbench Shows a BLOB Placeholder

BLOB means "binary large object." Workbench treats the value as opaque binary data because it does not know whether the bytes represent text, an image, compressed data, or something else.

That is why a query like this often shows a placeholder instead of readable content:

SELECT id, payload
FROM files;

In the result grid, the payload cell may appear as a BLOB marker rather than displaying the bytes directly. That behavior is normal. Workbench is protecting you from dumping raw binary into a text grid.

Open the Value in the Viewer

If you want to inspect one value directly inside Workbench, the usual approach is:

1. Run a query that selects the BLOB column.
2. Click the cell in the result grid.
3. Open the value viewer or editor from the cell context menu.
4. Switch to the text, binary, or hex-oriented view depending on the content.

This works best when the BLOB contains actual text bytes, JSON stored in binary form, or a small binary payload that you want to inspect manually.

For example, create a test table and insert a text payload into a BLOB:

1CREATE TABLE blob_demo (
2  id INT PRIMARY KEY AUTO_INCREMENT,
3  payload BLOB NOT NULL
4);
5
6INSERT INTO blob_demo (payload)
7VALUES (CAST('hello from mysql workbench' AS BINARY));
8
9SELECT id, payload
10FROM blob_demo;

The grid may still show a BLOB marker, but the viewer lets you inspect the actual bytes behind it.

Convert the BLOB in SQL When You Need Readable Output

If the BLOB really stores text, the most convenient way to see it is often to convert it in the query. That makes the result grid display a normal textual or hexadecimal value.

Show the bytes as hex

SELECT id, HEX(payload) AS payload_hex
FROM blob_demo;

Hex is the safest representation because it does not assume an encoding. It is useful when you are debugging hashes, binary tokens, UUID bytes, or protocol payloads.

Show the bytes as text

1SELECT
2  id,
3  CONVERT(payload USING utf8mb4) AS payload_text
4FROM blob_demo;

This is appropriate only when the bytes actually represent text in a known character set. If the encoding is wrong, the output will look garbled or may contain replacement characters.

Show the bytes as Base64

SELECT id, TO_BASE64(payload) AS payload_base64
FROM blob_demo;

Base64 is useful when you want a portable textual form that can be copied into logs, APIs, or test fixtures.

Choose the Right Representation

There is no single "best" way to view a BLOB because the right choice depends on what the data means.

Use the Workbench viewer when:

• you are inspecting one row manually
• you want to save or open the binary value
• you are not sure whether the bytes are text or binary

Use SQL conversion when:

• you want readable query output
• you need to compare many rows at once
• you are debugging binary values in joins, logs, or exports

For example, if a column stores SHA-256 hashes as binary bytes, HEX(payload) is far more useful than the raw viewer because you can compare values across many rows.

When the Column Is Mis-Typed

Sometimes the real issue is that the column should never have been a BLOB. If the application stores plain text or JSON in a BLOB column, Workbench is doing the reasonable thing by treating it as binary, but your schema may be fighting your tooling.

In that case, consider whether the column should be:

• 'TEXT or LONGTEXT for textual content'
• 'JSON for structured JSON data'
• 'VARCHAR for bounded string data'

Choosing the right column type makes queries, indexing, exports, and Workbench inspection much easier.

Common Pitfalls

The biggest mistake is assuming every BLOB is text. Casting arbitrary binary data to utf8mb4 can produce nonsense or hide the real issue.

Another common problem is trying to inspect very large BLOBs directly in the grid. Even if Workbench can open them, it is usually better to query metadata such as length first:

SELECT id, OCTET_LENGTH(payload) AS payload_size
FROM blob_demo;

Encoding confusion also causes trouble. If the bytes were encoded with a different character set before being inserted, CONVERT(payload USING utf8mb4) will not magically fix them.

Finally, do not confuse BINARY and VARBINARY display quirks with true BLOB storage. In some Workbench setups, binary string columns can also appear as blob-like values until you convert them explicitly in SQL.

Summary

• MySQL Workbench usually shows BLOB values as placeholders in the result grid.
• Use the cell viewer or editor when you want to inspect one value directly.
• Use HEX(), CONVERT(... USING utf8mb4), or TO_BASE64() when you need readable query output.
• Pick the representation based on whether the bytes are truly binary or actually text.
• If a column stores text, reconsider whether it should be a BLOB at all.