CSS text-overflow: ellipsis Doesn't Remove Text — The Four Truncation Layers and MySQL's Silent Data Loss Bug

CSS text-overflow: ellipsis hides text visually but doesn't remove it from the DOM — which means search engines can still index it, screen readers may still announce it, and users can still access it through browser "Find in page" — and this is often the correct behaviour for display truncation but the completely wrong behaviour for data-level truncation that must actually eliminate content

Truncation sits at an uncomfortable boundary between two concerns that are usually separated: presentation (how content looks) and data integrity (what content exists). Most developers learn CSS truncation without learning database truncation, and vice versa — creating gaps in understanding that produce real bugs when the two interact.

The four truncation layers and their different semantics

Layer 1 — CSS truncation (text-overflow: ellipsis):

• What it does: clips rendered text visually, adding an ellipsis character
• What it doesn't do: modify the DOM, change the text content, affect indexed content
• When correct: displaying long content in constrained UI space where full content is available elsewhere (title in a table row, description in a card)
• When wrong: as a substitute for genuine content limits, for content that must not be readable

Layer 2 — JavaScript truncation:

• What it does: creates a new string from the first N characters (or words/sentences), potentially adding ellipsis
• What it doesn't do: affect the original data; only modifies what's passed to the DOM
• When correct: generating preview text for SEO meta descriptions, email subject lines, notification previews
• When wrong: if the original full string is also accessible via the DOM

Layer 3 — Backend/API truncation:

• What it does: limits the length of data returned by the API (e.g., abstract[:200] in Python)
• What it doesn't do: affect the stored data
• When correct: generating safe preview content in API responses where full content is separately available
• When wrong: when the truncated output is the only copy and the original full content is needed later

Layer 4 — Database truncation:

• What it does: physically limits or silently cuts stored data to fit a column's defined size
• What it doesn't do: warn you in default configurations (silent truncation)
• When correct: never silently — should always be a validated constraint with explicit error handling
• When wrong: always, when it happens without explicit application-level validation

The silent database truncation problem in detail

MySQL's default (non-strict) mode silently truncates strings that exceed VARCHAR(n) column definitions:

CREATE TABLE articles (title VARCHAR(100));
INSERT INTO articles (title) VALUES (REPEAT('a', 150));
-- MySQL default: silently inserts 100 characters, discards 50
-- No error, no warning unless strict mode is enabled

PostgreSQL always raises an error:

INSERT INTO articles (title) VALUES (REPEAT('a', 150));
-- ERROR: value too long for type character varying(100)

The production scenario that creates bugs:

1. Developer tests with short strings — everything works
2. User submits a long title (150 characters)
3. MySQL silently saves 100 characters
4. User returns to edit their article and sees a different, shorter title than what they submitted
5. User re-edits the now-truncated title, submitting another 150 characters
6. Same silent truncation occurs
7. User loses content with no error, no explanation

The fix: validate at the application layer before the database call:

if len(title) > 100:
    raise ValueError(f"Title must be 100 characters or fewer, got {len(title)}")

Or enable MySQL strict mode, which converts silent truncation into an explicit error.

Windows MAX_PATH and filesystem truncation

Windows traditionally limits file paths to MAX_PATH (260 characters, including the null terminator), covering drive letter, path separators, filename, and extension. This limit dates to MS-DOS and early Windows.

Where truncation occurs: applications that construct file paths by concatenating directory names and filenames without checking total length either silently truncate the path (failing to open the file) or raise an error that's often poorly communicated to users.

Common scenarios where this bites:

• Deep project directories checked out from version control (node_modules with nested dependencies often exceeds 260 characters)
• Automated report generation that uses long descriptive filenames in deep directory structures
• File synchronisation tools (Dropbox, OneDrive) that encounter files from systems without path length limits

The Windows 10/11 fix: Group Policy can enable long path support (paths up to 32,767 characters) — both the system setting and per-application manifest must opt in. Git for Windows does this automatically. Many applications do not.

Text truncation for SEO meta descriptions

Meta description optimal length is a truncation problem with specific thresholds:

Google's character display limit: approximately 155-160 characters in most SERP contexts, though Google rewrites meta descriptions frequently (approximately 70% of the time) and uses the search query to determine the best snippet regardless of the meta description content.

The truncation cliff: a meta description truncated mid-sentence (because it exceeded the character limit) looks worse in search results than a slightly shorter but complete sentence. Writing to approximately 145-150 characters (slightly under the limit) provides a buffer for character rendering differences (wide characters like M and W take more pixel space than i and l).

Word vs character boundary truncation: truncating at 155 characters regardless of word boundary can split words. Well-implemented meta description truncation uses word boundaries and ensures the result ends with a complete sentence or meaningful phrase.

How to use the Text Truncator on sadiqbd.com

1. For meta description preparation: truncate title and description text to the appropriate character limits before entering them in CMS fields or meta tag generators — the tool allows specifying exact character count with word-boundary awareness to avoid mid-word cuts
2. For notification and alert text: mobile push notifications, email subject lines, and social previews each have different character limits (iOS push ~110 visible characters, Android ~65 visible characters, email subjects vary by client) — the tool helps produce correct-length strings for each context
3. For data validation testing: generate strings at exactly n, n+1, and n-1 characters relative to your database field's VARCHAR limit to test that your application's validation layer correctly rejects strings above the limit before they reach the database

Frequently Asked Questions

Should I truncate text at the frontend (CSS or JavaScript) or the backend, and does it matter for SEO? It depends entirely on what the truncation is for. Frontend CSS truncation (text-overflow: ellipsis) is purely visual — the full text still exists in the DOM, gets indexed by search engines, and is accessible to users who look for it. This is correct for UI display of content whose full version is accessible elsewhere (a hover tooltip, an expand button, a link to the full article). Backend truncation produces shorter actual strings — smaller DOM content that gets indexed, smaller data stored, smaller API responses. For SEO, the content that exists in the HTML is what gets indexed, regardless of whether CSS visually hides part of it. If you want Google to index only the first 200 words of a summary, you must truncate at the backend or API layer — CSS truncation doesn't help.

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

Try the Text Truncator free at sadiqbd.com — shorten any text to an exact character or word limit with smart word-boundary detection.