If you've ever built an n8n workflow that scrapes or processes LinkedIn profile data, you've almost certainly run into a frustrating problem: the follower and connection count statistics come back in completely different formats depending on the user's region. What appears as 1,234 in the US looks like 1.234 in Germany, and Chinese LinkedIn users often see abbreviated formats like 1.2万 (meaning 12,000). If your workflow treats all of these as plain text strings and tries to do arithmetic, it breaks — silently or loudly.

This article walks through a practical n8n workflow fix that correctly normalises LinkedIn profile statistics regardless of whether the source data originates from the USA, EU, or China.

Why LinkedIn Statistics Break in n8n

The root cause is simple: LinkedIn renders numbers in the locale of the viewing user's account, not the profile owner's locale. When your n8n workflow fetches profile data — whether through the LinkedIn API, a scraping node, or a browser automation tool — the raw value you receive is a locale-formatted string, not a clean integer.

Region	Raw value received	Actual number
🇺🇸 USA	12,450	12,450
🇩🇪 Germany / EU	12.450	12,450
🇫🇷 France / EU	12 450	12,450
🇨🇳 China	1.2万	12,000
🇨🇳 China (large)	120万	1,200,000

The problem is compounded by the fact that n8n's built-in number parsing assumes a US/UK format. Passing 12.450 to a math node will give you 12.45 — off by a factor of 1,000.

The Fix: A Normalisation Function Node

The cleanest solution is to add a Code node (JavaScript) immediately after any node that returns LinkedIn profile statistics. This node detects the format and converts all variants to a plain integer.

Step 1 — Identify the input field

Assume your previous node returns a field called followersCount as a string. Your Code node will read this, normalise it, and output a clean followersNormalised integer.

Step 2 — Add the Code node

// LinkedIn Statistics Normaliser — USA / EU / China
// Handles: "12,450" | "12.450" | "12 450" | "1.2万" | "120万"

function normaliseLinkedInStat(raw) {
  if (!raw) return 0;
  let s = String(raw).trim();

  // Chinese wan (万) format: 1.2万 = 12000, 120万 = 1200000
  if (s.includes('万')) {
    const num = parseFloat(s.replace('万', '').trim());
    return Math.round(num * 10000);
  }

  // French/Swiss EU format: space as thousands separator "12 450"
  if (/^\d[\d ]+\d$/.test(s)) {
    return parseInt(s.replace(/\s/g, ''), 10);
  }

  // Detect EU format: period as thousands separator (e.g. "12.450")
  // Rule: if period appears and is followed by exactly 3 digits at end → thousands sep
  if (/\d\.\d{3}$/.test(s) && !s.includes(',')) {
    return parseInt(s.replace(/\./g, ''), 10);
  }

  // US/UK format: comma as thousands separator "12,450"
  if (s.includes(',')) {
    return parseInt(s.replace(/,/g, ''), 10);
  }

  // Plain number
  return parseInt(s, 10) || 0;
}

return items.map(item => {
  const raw = item.json.followersCount;
  return {
    json: {
      ...item.json,
      followersNormalised: normaliseLinkedInStat(raw)
    }
  };
});

Step 3 — Test with Sample Data

Pin the following test data to your Code node and verify the outputs:

Input	Expected output	Region
"12,450"	12450	USA
"12.450"	12450	Germany / EU
"12 450"	12450	France / EU
"1.2万"	12000	China
"120万"	1200000	China
"500"	500	Any

Where to Place This Node in Your Workflow

The normalisation node should sit between your data-fetch node and any downstream logic that uses numeric comparisons, aggregations, or exports:

Regional Edge Cases to Watch For

• China — 亿 (yì): For very large pages, LinkedIn China may use 亿 (100 million). Add a check: if (s.includes('亿')) return Math.round(parseFloat(s) * 100000000);
• India / South Asia: Large numbers may use the lakh format (1,23,456). This is less common on LinkedIn but worth noting for high-traffic automation.
• Abbreviated "K" / "M": LinkedIn sometimes abbreviates very large counts to 12K or 1.2M. Extend the function with: if (s.endsWith('K')) return Math.round(parseFloat(s) * 1000);

Summary

LinkedIn profile statistics arrive in locale-specific string formats that silently break numeric operations in n8n workflows. A single Code node with a 30-line normalisation function handles all major regional variants — US comma-separated, EU dot-separated, French space-separated, and Chinese 万/亿 abbreviated formats — converting them to clean integers your workflow can safely use.

This fix takes under 10 minutes to implement and eliminates an entire class of hard-to-debug data errors in LinkedIn automation workflows.