Detect and Fix String-Encoded Numerics in Stata
Stata imports may store numeric-looking variables as strings, breaking analysis commands. Learn to detect the type with describe and convert safely using destring.
05 Jan 2026, 09:58 UTC

Detect and Fix String-Encoded Numerics in Stata
When a Stata dataset contains variables that look like numbers but are stored as strings, analysis commands such as summarize or regress will fail with a type mismatch error. This commonly occurs when imported data includes currency symbols, commas, or extra whitespace that prevents Stata from inferring a numeric type.
Mechanism: How Stata Infers Variable Types
Stata determines a variable’s type during the use operation by scanning the first 100 observations. If any value contains a non-numeric character outside of a leading sign or decimal point, the variable is assigned a string type, denoted as str# in the variable label. This conservative inference prevents silent data corruption but requires you to explicitly convert types before performing numeric operations.
Worked Configuration Example
Assume a dataset survey.dta exists in the current working directory and contains an income variable with values formatted as currency.
use survey.dta
describeRun these commands in the Stata Command window. Permissions: read access to the .dta file in the current directory is sufficient. Expected check: the describe output will list income as str8 (or similar), indicating a string variable.
destring income, replaceAfter running destring income, replace, re-run describe. The income variable should now appear as float or double, depending on precision. You can then execute summarize income to view mean, standard deviation, and other statistics.
Note: The force option of destring will remove any non-numeric characters, which may silently discard information such as currency labels. Use it only after verifying that the symbols are extraneous.
Limits and Common Mistakes
The primary limitation is memory: Stata processes the active dataset in RAM, and excessively large files may cause exhaustion errors. A common mistake is applying destring or tostring without first inspecting the variable’s content, which can convert meaningful string values (e.g., N/A) into missing numbers (.), breaking downstream analysis. Always cross-check a few actual values using list income in 1/5 or codebook income before mass conversion.
Practical Verification
After converting a variable, confirm the change by running summarize income and verifying that the returned statistics are numeric. If the variable was originally intended to retain text labels, use encode income, gen(income_code) to create a numeric coding that preserves the original strings as a separate dataset variable.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.