Truncation Bugs: Database VARCHAR Silent Data Loss, CSS Overflow, and Windows Path Length Limits

Database VARCHAR truncation is a silent data corruption bug — and it's been causing production incidents for decades

A database column defined as VARCHAR(255) silently truncates any string longer than 255 characters in MySQL's default configuration. The application code receives no error. The user sees no error. The data is written — just with the last characters missing. This behaviour, known as "silent truncation," has been the source of data loss bugs in countless production systems.

Understanding how truncation works at different layers — database columns, CSS text overflow, API response fields, and operating system paths — prevents a category of subtle, hard-to-diagnose bugs.

---

Database truncation: the VARCHAR problem

MySQL's default behaviour:

In MySQL's default STRICT_TRANS_TABLES mode (the MySQL 5.7.5+ default), inserting a string longer than the column definition raises an error. But in older MySQL or with STRICT_TRANS_TABLES disabled, MySQL silently truncates:

CREATE TABLE users (bio VARCHAR(255));

-- With strict mode OFF (older/misconfigured MySQL):
INSERT INTO users (bio) VALUES (REPEAT('a', 300));
-- No error raised. Stores 255 characters silently.

SELECT LENGTH(bio) FROM users;
-- → 255 (truncated without notification)

PostgreSQL's behaviour: PostgreSQL is stricter — it raises a value too long for type character varying(255) error rather than silently truncating. This is why PostgreSQL is generally preferred for applications where data integrity is critical.

The fix: enable strict mode in MySQL, use TEXT type instead of VARCHAR for user-generated content of unpredictable length, and validate string length in application code before writing.

---

CSS truncation: the right way to show abbreviated text

CSS provides three mechanisms for truncating text that overflows its container.

Single-line truncation with ellipsis:

.truncate-single {
  white-space: nowrap;      /* Prevent wrapping */
  overflow: hidden;         /* Hide overflowing text */
  text-overflow: ellipsis;  /* Show ... at truncation point */
  max-width: 200px;         /* Container must have a width */
}

This produces text that shows as "This is a long title th..." — the most common truncation pattern in UI components (card titles, table cells, file names).

Multi-line truncation (CSS -webkit-line-clamp):

.truncate-multiline {
  display: -webkit-box;
  -webkit-line-clamp: 3;    /* Maximum 3 lines */
  -webkit-box-orient: vertical;
  overflow: hidden;
}

Despite the -webkit- prefix, this is now widely supported across all modern browsers (unprefixed support added in Chrome 98, Firefox 68, Safari 13). This produces text clamped at 3 lines with an ellipsis.

Container query-based truncation: modern CSS allows truncation based on container size (not viewport size) — useful for components that appear at different sizes in different contexts.

---

The accessibility problem with truncated text

Visual truncation creates an accessibility concern: screen readers read the full text regardless of CSS truncation, but sighted users see the abbreviated version. The content accessible to screen reader users (all of it) differs from what sighted users see (truncated).

Best practices for accessible truncation:

Option 1: title attribute for single-line truncation:

<td class="truncate-single" title="Full Company Name That's Very Long">
  Full Company Name That's...
</td>

The title attribute provides a tooltip with the full text and is accessible to screen readers as a fallback.

Option 2: aria-label:

<div class="truncate-multiline" aria-label="Complete full text for assistive technology">
  Visual text that gets truncated...
</div>

Option 3: visually hidden full text:

<div class="truncate-single">
  Short visible text
  <span class="visually-hidden">Full text for screen readers</span>
</div>

WCAG Success Criterion 1.4.4 (Resize Text) and 1.4.12 (Text Spacing) both have implications for truncated text — ensure content remains understandable when text spacing is increased.

---

API response truncation: handling limits in external APIs

Many APIs truncate fields in responses. Twitter's original 140-character limit (later 280) was enforced at the API level — text beyond the limit was rejected at post time, not truncated silently.

Other APIs truncate more subtly. Some search APIs truncate long descriptions or snippets. Log aggregation APIs may truncate log message strings. Understanding which fields have limits in an API you're consuming is important for:

• Not losing data when storing API responses
• Not displaying truncated text to users without knowing it's truncated
• Properly handling the response format (truncated strings sometimes have a flag or count field indicating the original length)

A common pattern in APIs: the "truncated" flag:

{
  "description": "This is a long description that has been tr...",
  "description_truncated": true,
  "description_length": 5000
}

When this flag is absent, consumers may not know the field has been truncated.

---

File system path length limits

Operating systems impose maximum path length limits that are a form of text truncation:

OS	Default max path length	Notes
Windows (legacy)	260 characters (MAX_PATH)	Extended paths up to 32,767 chars available with opt-in
Windows (modern)	Up to 32,767 (with Long Path support enabled)	Group Policy or registry setting required
Linux	4,096 characters	Defined by PATH_MAX
macOS	1,024 characters	PATH_MAX

The Windows 260-char limit has caused real problems: deeply nested directory structures in node_modules, Django, and other frameworks can exceed 260 characters, causing mysterious failures on Windows when the same code works on Linux.

The fix: Windows 10 1607+ can enable long path support, or paths can be formatted with the \\?\ prefix to opt into extended-length path handling.

---

How to use the Text Truncator on sadiqbd.com

1. Enter text and desired limit (characters or words)
2. Truncate — see the shortened text with appropriate ellipsis
3. Use for:
   • Testing how content looks at different character limits
   • Preparing social media copy at specific character counts
   • Generating database-safe versions of user input before storage
   • Creating preview snippets for search results or cards

---

Frequently Asked Questions

How does JavaScript's substring() differ from slice() for truncation? substring(0, 100) and slice(0, 100) are equivalent for positive indices. Differences appear with negative indices: slice(-3) returns the last 3 characters; substring(-3) treats negative numbers as 0. For simple character-count truncation, both work identically.

How do I truncate at word boundaries rather than character boundaries in code?

function truncateAtWord(text, limit) {
    if (text.length <= limit) return text;
    const truncated = text.slice(0, limit);
    return truncated.slice(0, truncated.lastIndexOf(' ')) + '...';
}

This finds the last space before the character limit and truncates there — producing word-boundary truncation.

Is the Text Truncator free? Yes — completely free, no sign-up required.

---

Truncation is one of the most invisible bugs in software — silent database truncation loses data without warning, CSS truncation hides content without accessibility fallback, and path length limits cause unexplained build failures. Understanding every truncation point in your stack prevents the category of "where did that data go?" incidents.

Try the Text Truncator free at sadiqbd.com — truncate any text to a specific character or word limit with proper ellipsis handling.