ASC File

What are ASC files and how to open them

Are you having problems opening an ASC file or are you simply curious about its contents? We're here to explain the properties of these files and provide you with software that can open or handle your ASC files.

What is an ASC file?

ASC files have multiple uses, and 16bit DOS COM COMT Text Converted is one of them. Read more about the other uses further down the page.

16bit DOS COM COMT Text Converted File

This format represents a DOS‐COM executable that has been transformed into plain ASCII text by the COMT encoder so that it can be sent over text‐only channels but still remain valid as a runnable 16-bit COM file under DOS when reassembled. In its original form a COM file holds executable machine code for MS-DOS. The COMT process encodes every machine-code byte into readable text (or text-like characters), adds a short decoder stub (loader) at the start, and optionally wraps the whole in explanatory "wrapper" lines giving instructions. The result is a file readable as text, but executable (in its transformed form) if the content is transferred in text mode and saved without corruption.

Files are produced by the COMT utility. One invokes COMT on a standard DOS COM executable; the utility encodes the file using either a "1-to-2" method (one binary byte becomes two ASCII characters) for small files, or "3-to-4" for larger files, and prepends a small decoding stub so that the file still runs under DOS. If the -w command-line option ("wrapper") is used, the output is given a wrapper: extra text before and after the encoded data explaining how to extract or use it, and the filename inside the wrapper specifies what the embedded COM file's name should be. The wrapper causes the file's extension to change to text format (.ASC) instead of .COM.

A reliable identifier at the start of this format is the ASCII signature string beginning at offset zero: ThisfilehasbeenencodedwiththeCOMTencoder\r\n Files encoded with COMT in wrapper mode will include that exact line as their first bytes.

How to open ASC files

Important: Different programs may use files with the ASC file extension for different purposes, so unless you are sure which format your ASC file is, you may need to try a few different programs.

While we have not verified the apps ourselves yet, our users have suggested ten different ASC openers which you will find listed below.

Last updated: August 21, 2026

All known file formats using extension .ASC

While 16bit DOS COM COMT Text Converted File is a popular type of ASC-file, we know of 23 different uses of the .ASC file extension. Different software may use files with the same extension for different types of data.

3D Studio ASCII Format

The 3D Studio ASCII Format with the extension .ASC is a text-based 3D scene description format created by Discreet for use with Autodesk 3ds Max (formerly Discreet 3D Studio) to represent mesh geometry, materials, lights, cameras and basic animation data in a human-readable form. It is meant as an interchange format to export 3D objects and scenes so they can be viewed or edited by other systems capable of parsing plain ASCII text.

Files in this format are produced by 3ds Max or plugins that support exporting to "ASC / Autodesk 3D Studio ASCII," and are consumed similarly by 3ds Max and compatible viewers or tools. Inside the format, each object has its name, transformation matrix, mesh geometry including vertices and faces (often as a "tri-mesh"), possibly UV texture coordinates and material assignments, as well as information about lights, cameras, and materials. Some viewers may ignore smooth grouping or emissive material color.

An ASC file begins with human-readable ASCII header and keywords. Among technical markers are strings such as NAMED OBJECT, VERTEX LIST, FACE LIST, TRI-MESH, VERTEX 0, VERTICES, FACE 0, FACES. At the very start may appear "Ambientlightcolor:" as ASCII text. These signatures can help in detecting the file type and parsing its structure.

ASC opener for Windows

We have identified one ASC opener that is compatible with this specific type of ASC file.

3DX 3D Model

3DX 3D model files store mesh geometry and material definitions in an ASCII text format exported by the 3DXExp plugin for 3DS MAX, used jointly with the View3DX viewer. They enable exporting static 3D models - including vertices, faces, texture coordinates, normals and material properties - for viewing without the full 3DS MAX environment.

These files are produced by the 3DXExp plugin. A 3DX model begins with a version header, followed by one or more object blocks. Each object block gives its name and counts for vertices, texture vertices, faces, materials, and optionally normals. Materials include diffuse/specular colors, texture names or flags like NODIFFUSE, and options such as TWOSIDED. Faces reference vertices by index, include smoothing group info, and if texture vertices are present, texture faces mapping those indices.

The format is entirely case-sensitive and human-readable. Each file starts with the ASCII header "3DX File 1.0", followed by keywords like NUMOBJECTS, MATERIAL LIST, TVERTEX LIST, FACE LIST etc. These sections are mandatory or conditional based on earlier declared counts (e.g. TVertices > 0 means texture vertex data will appear). Material sections can specify TEXTURE (or use flags like NODIFFUSE), SMOOTHING is a bitmask per face, options such as NORMALS may be included.

ActionScript Communication File

Files that contain the .asc file extension are script files that have been written in the ActionScript programming language. These files contain code that is used to control Flash-based applications.

The code stored in the ASC files is executed by the Flash Media Server. It can control various events, such as how the server accesses resources, streams multimedia content to a user, and loads Flash applications. The ASC files can be created by the Adobe Media Encoder or Adobe Flash Media Live Encoder.

ASCII Encoded HP 48 Object File

This format stores objects created by the HP-48 scientific/calculating device in a plain text form so that any binary object can be transferred over channels that only support ASCII, such as e-mail, bulletin boards, or basic file-transfer tools. The encoding was invented to make programs, data arrays, strings, graphics objects, libraries, and other HP-48 object types portable even when only text communication is possible.

Typically the HP-48 generates an ASCII string using a function called →ASC which takes any object in calculator memory (level 1) and turns it into an encoded text string. The reverse operation, ASC→, takes such a string and reconstructs the original HP-48 object inside the calculator. A checksum is embedded in the text encoding so that corruption during transmission is detectable. Some object types that are normally only handled in binary can still be converted this way. Transfer tools on the calculator such as File Manager offer ASCII mode when sending objects to the PC. Transfer settings like translation mechanism, angle mode, and fraction mark are saved in an ASCII header so that numerical and formatting settings match what was on the HP‐48.

The internal identification starts with the ASCII characters % % H P : (i.e. "%%HP:") at file beginning to mark the start of an ASCII encoded HP-48 object.

Atlantis SpellCheck Configuration File

Atlantis SpellCheck Configuration File is a plain-text configuration used by Atlantis Word Processor to capture the current spellchecking and dictionary settings, along with which custom dictionaries (lexicons) are enabled. It's exported from Atlantis via the Save to File command in the Spellcheck or Options dialog, and can later be restored using the Load from File command.

Atlantis Word Processor writes this file when the user chooses to save their spellcheck settings. The file records options such as which spellcheckers and dictionaries are active, ignore rules (such as ignoring words in internet addresses, mixed-case words, words with numbers), and any custom lexicons that have been added. Atlantis reads the file back via the Load from File feature to reapply those settings.

The file begins with a line "[General]" and includes sections and entries using keywords such as LANGUAGE, LEXICON, COUNT, along with references to lexicon file extensions like .TLX or .ZLX. It contains strings like EDITABLE LEXICONS and FIXED LEXICONS. These internal identifiers help Atlantis locate and categorize each dictionary and its type of editability.

Attocube Systems 2D Data

Attocube Systems 2D Data files store surface scan measurements produced by the Daisy software together with the ASC500 scanning probe controller. They hold two-dimensional raster-scan data (such as height or signal maps) in plain text form, capturing forward and backward scan directions, digital or analog signals, either raw data or after user-selected filtering. Tools that visualize topography, step scans, second pass scans, or similar 2D probe-microscopy signals generate these files for later analysis or image‐processing.

Data are produced when the user triggers a snapshot in a SCAN-type display in Daisy. The program writes out ASCII text representing the data either unprocessed (RAW) or as shown on screen (DISPLAYED), one file each for forward and backward scan directions where appropriate. File size is larger - typically 2-5× - than binary equivalent formats. Preference settings allow choosing between "line-oriented" form (rows of data separated by TABs, each row ending with a line feed) or each data point on its own line. Early in the scan file, a human-readable header gives context (display name, number of pixels, signal units, etc.), followed by the numerical data in rows and columns.

Files begin with an ASCII signature "#Daisy…", which can be used to identify them.

BRL-CAD Geometry File

The BRL-CAD Geometry File is an ASCII text version of a BRL-CAD geometry database used in the BRL-CAD modeling system. It represents all the shapes, combinations, attributes, and transformations of a CSG (Constructive Solid Geometry) model in a human-readable text script or record format. The file is useful for exporting a full geometry database to a plain text form, for editing, version control, inspection, or transferring between platforms.

Files in this format are produced by g2asc, a BRL-CAD utility that converts a standard binary geometry database into text. Conversely, asc2g reads these ASCII geometry files and rebuilds the binary database (in the current "v5" format), whether starting from a legacy line-record format or the newer TCL-command-script style. Thus this format acts as an interchange or intermediary form rather than BRL-CAD's internal working format.

The newer ASCII form (since BRL-CAD version 6.0) uses a Tcl script consisting of commands like put, attr, color and title, which when sourced by BRL-CAD or converted via asc2g recreates the database. The older, legacy ASCII form uses one-line records tied to the prior database layout. Both ASCII forms are accepted as inputs by asc2g.

The binary geometry database format (".g") that the ASCII file converts to and from stores data in a machine-independent binary format: floating point values as IEEE double precision, integers in big-endian order, and character strings as ASCII with explicit length fields.

Cheetah Subtitles File

Cheetah Subtitles File is a text-based caption file format used for closed captioning and subtitling workflows. It provides subtitle text with associated timecodes and display instructions in a structured ASCII layout. The format is designed to be both machinable and editable by humans without needing a proprietary binary tool.

This format is usually created by Cheetah or CaptionMaker software. These programs export readable text files where each caption event includes a start timecode, alignment or region tags (such as TopDown or BottomUp), display mode tags like PopOn or PaintOn, optional width or color parameters, and the caption text. After export, the file may be processed or translated into broadcast-binary formats or embedded in video workflows, depending on broadcaster or subtitle authoring requirements.

Individual caption entries begin with markers like "Caption Number N" followed by a timecode, a directional or display mode tag (for example BottomUp, TopDown, PopOn) plus optional style or position modifiers such as Width or color code (e.g. Cb16). Then the textual content follows, often terminated with an "\E" control to signal end of the entry. These control words and markers serve to identify the caption's order, orientation, layout, and style within the overall subtitle set. The file begins with a distinctive signature (for example "NonDropFrame..Width") to indicate key format versioning or frame timing mode.

ENVI ASCII Plot

ENVI ASCII Plot files store curve or spectral-plot data produced by the ENVI software from NV5 Geospatial Solutions. They are text‐based exports capturing multiple related data series (columns), such as wavelength versus reflectance or mean and standard deviation curves derived from regions of interest. The format is useful for analyzing spectral signatures, comparing measurements, or importing/exporting plot data between profiles or spectral libraries.

ENVI writes these files when a user exports plot or spectral profile data via the plot window or spectral library viewer in ENVI. Importing works via the same modules, allowing the user to select which column holds the X‐axis values (often wavelengths) and which hold the Y‐axis values (such as measurement values). Lines at the top beginning with descriptive text label each column, followed by rows of numerical data. White space or delimiters separate values; lines starting with semicolons or non‐numeric text are skipped in import.

Files begin with a header line containing the exact ASCII signature "ENVI ASCII Plot File" and include labels like "Column 1: Wavelength" and "Column 2:" etc. Subsequent data rows contain floating‐point numbers aligned in columns.

Esri Grid ASCII Data File

Esri Grid ASCII Data File (also called Arc/Info ASCII Grid) is a simple text‐based raster format used for storing numeric spatial data in a regular grid. It is produced by Esri GIS software such as ArcInfo Workstation (using GRIDASCII) and by tools like ArcGIS's Raster to ASCII exporter. It serves mainly as an interchange format: it converts a raster dataset into a human-readable grid of numbers so that other GIS or scientific software can import it.

The file starts with six header lines that define grid geometry and spatial referencing. Key header keywords include NCOLS and NROWS (number of columns and rows), XLLCORNER or XLLCENTER and YLLCORNER or YLLCENTER (coordinates of lower left origin, by corner or center), CELLSIZE (side length of each square cell), and an optional NODATA_VALUE to mark missing or undefined cells. After the header, cell values follow in row-major order: the first data row corresponds to the top of the raster, each row's values go left to right, then proceed downward. Cells can store either integer or floating point numbers.

The format is purely ASCII text, which makes files relatively large compared to binary grids and less efficient for very large datasets; because of this, Esri documentation notes that it is typically used for data exchange rather than for storage of big grids. The spatial coordinate system itself is not encoded inside the file: often an accompanying projection file (for example with .prj extension) supplies that information.

Internally the file can be identified by specific text signatures: it begins (at offset 0) with "ncols ", contains header keywords such as NROWS, XLLCORNER (or XLLCENTER), YLLCORNER (or YLLCENTER), CELLSIZE, and the string "NODATA_VALUE".

LTSpice Circuit Schematic File

LTSpice schematics are stored in files created by the LTSpice program (originally by Linear Technology, now Analog Devices). These files hold the visual design of an electronic circuit - where components go, how they're connected, wire paths, labels, values - so the user can draw, view, edit, then invoke simulation. The schematic creator writes these files; LTSpice reads them to display and manage the circuit and to extract a netlist for simulation.

These schematic description files are plain-text and human-readable. They include a header declaring version and sheet size (e.g. width and height), then many lines each beginning with keywords that describe graphic or electrical elements: wires, components (symbols), attributes for component values and names, labels for nets, and free text or SPICE directives. Graphic decorations (lines, boxes, circles) also may be included. The format encodes how component symbols are to be placed, rotated or mirrored.

Internal structure is identified by characteristic keywords: the file begins with something like "Version 4" followed by a "SHEET" line. Component instances are marked with lines starting "SYMBOL", followed by "SYMATTR" and "WINDOW" lines defining instance names, component values, and text label positioning. Wire segments use "WIRE", net labels use "FLAG", arbitrary text or directives use "TEXT". These identifiers allow parsing tools to reconstruct both how the circuit looks and what it does.

PGP ASCII-Armor File

Pretty Good Privacy ASCII-Armored files store PGP data - such as encrypted messages, signatures, or public and private keys - in a text-friendly form so that binary data can be sent over channels that only support plain text. The ASCII armor wraps the binary PGP content in a standard structure that includes header lines indicating the type of data, optional text headers like version or comments, and a body encoded in a radix-64 (Base64-like) scheme. Ultimately it makes cryptographic output easier to read, share, and transmit without corruption when the medium cannot handle raw binary.

These files are produced by PGP or OpenPGP tools when one chooses the "armor" or "ASCII" output option. Encryption, signing, or key export operations can generate ASCII-armored versions for secure storage or transport. When reading, PGP or compatible software decodes the radix-64 text back into the original binary, verifies an included CRC or checksum if present, and then processes encryption, signature verification, or key usage accordingly.

Technical identifiers include headers and tails such as "-----BEGIN PGP MESSAGE-----" or "-----BEGIN PGP PUBLIC KEY BLOCK-----" at the beginning, and matching "-----END … -----" lines. Between them are optional Armor Headers like "Version:" or "Comment:", then a blank line, the base64-encoded data, and an optional CRC checksum line starting with "=". Equity with OpenPGP implementations as defined in RFC 4880 ensures consistent formatting.

PGP Clear-Text Signed Message File

A PGP Clear-Text Signed Message File contains a text message that has been digitally signed using OpenPGP, so that the message remains readable but carries a cryptographic signature verifying its integrity and origin. It is produced by PGP or compatible OpenPGP tools when someone wants to show what was signed without hiding the content.

The original message text is preserved (with only canonical adjustments), followed by an ASCII-armored signature block. The signing program processes the text (converting line endings to canonical <CR><LF>, removing trailing whitespace on each line), computes a hash, signs that hash using a private key, and then appends a signature that is ASCII-armored. Verification tools strip out or reverse dash-escaping, recompute the hash, and check the signature using the corresponding public key.

Internal identifiers include the header line -----BEGIN PGP SIGNED MESSAGE----- at the start, then one or more "Hash:" Armor Header lines; then a blank line; then the dash-escaped cleartext; and finally an ASCII armored signature section enclosed between -----BEGIN PGP SIGNATURE----- and -----END PGP SIGNATURE-----.

PGP Message File

A PGP Message File contains text that holds a message encrypted (and sometimes signed or compressed) using Pretty Good Privacy (PGP) in its ASCII-armored form. Such files preserve privacy and authenticity by using public-key cryptography and are designed for easy transmission over systems that expect readable text.

These files are produced by PGP or compatible tools like GnuPG or any implementation of the OpenPGP standard. The message inside is first optionally compressed, optionally signed, then encrypted. After encryption, the binary data is wrapped in an ASCII-armoring process (sometimes called Radix-64) so that the output consists entirely of printable ASCII characters and is safe for transport via email or text‐based channels.

When decoded, the ASCII armor is removed, the binary data is decrypted using the recipient's private key (or symmetric key, depending on how it was encrypted), signatures (if present) are verified, and any decompression is reversed. The sequence of processing ensures that the message arrives intact and unaltered, with proof of its origin if signed.

Technically such files begin with a header line such as "-----BEGIN PGP MESSAGE-----" and end with a matching footer "-----END PGP MESSAGE-----". Between them there may be ASCII‐headers (for example Version: or Comment:), followed by a blank line, lines of Radix-64 (base64) encoded data, a checksum line starting with "=" and the footer line.

PGP Private/Public Key Block

PGP Private/Public Key Block files store cryptographic key pairs or single keys used for securing email, files, or other data. They conform to the OpenPGP standard, allowing either a public key alone, a private (secret) key alone, or both together. Such files are generated by OpenPGP-compliant tools when exporting or backing up keys, enabling them to be shared or imported reliably.

These key blocks are encoded using ASCII Armor so that binary key material can be safely transmitted via text-only channels such as email. The text starts with a header line indicating whether the block holds a public key or a private key (e.g. BEGIN PGP PUBLIC KEY BLOCK, BEGIN PGP PRIVATE KEY BLOCK), includes optional metadata ("Version", "Comment", etc.), followed by Base64-encoded OpenPGP packet data, then a checksum, and a matching footer line. After creation, they are usually imported into a user's keyring where they can be used to encrypt, decrypt, sign, or verify data according to whether the private or public portion is present.

Internally the packet data follows OpenPGP message formats as defined in RFC 9580. Secret key packets include public key fields plus private key data, possibly encrypted using a passphrase-derived key (S2K specifier). Public key packets contain version, creation timestamp, key algorithm identifier, and algorithm-specific key material. Private key blocks begin with "-----BEGIN PGP PRIVATE KEY BLOCK-----" or "-----BEGIN PGP PUBLIC KEY BLOCK-----", include the armored Base64 data, and end with "-----END PGP PRIVATE KEY BLOCK-----" or "-----END PGP PUBLIC KEY BLOCK-----" respectively.

PGP Signature File

A PGP Signature File holds a digital signature produced by Pretty Good Privacy or OpenPGP software for a specific file or message. It verifies data integrity and authenticity without containing the original content itself. Its main purpose is to prove that someone with a known private key created the signature and that the signed content hasn't been altered since signing.

The format comes from OpenPGP's ASCII-armoring system, which converts binary signature data into text form so it can be shared safely via email or text-based systems. The signature is detached, meaning the signature file stands alone and must be checked against the original file or message. To verify it, the verifying software uses the signer's public key to decrypt the hash in the signature, independently re-computes the hash from the original content, and checks for a match.

Internally the file starts with a header line "-----BEGIN PGP SIGNATURE-----", then optional metadata headers like Version, Comment, and Hash algorithm, a blank line, base64-encoded signature data, a checksum, and ends with "-----END PGP SIGNATURE-----". It uses OpenPGP's ASCII armor rules and represents the signature packet as specified in RFC 2440.

Rigaku Smartlab Pole Figure Raw Format File

Rigaku Smartlab Pole Figure Raw Format files store the data and settings from a pole-figure measurement made by Rigaku's SmartLab X-ray diffractometer. These files are written by the SmartLab system when one opts to save "RINT ASCII" (ASCII-text) output along with pole-figure measurements. They provide both the measurement intensities (texture data) and full metadata about how the measurement was configured: angles, axes, sample identification, scan parameters, wavelength, etc.

In typical use the format is created alongside a RAS or RAW file: when the instrument is set to "Save RAS and RINT ASCII format files," a pole-figure scan will produce an ASCII file in this format. The file can then be used for texture processing and orientation distribution (ODF) analysis in software like LaboTex or SmartLab Studio II. The ASCII version is preferred for human inspection and for compatibility with analysis tools.

Inside the file, metadata is encoded with keyword tags preceded by an asterisk (""). These include fields like STD_MATERIAL, PF_2THANGLE, PF_METHOD, PF_AANGLE, PF_BANGLE, PF_STEP, PF_START, PF_STOP, ATTACHMENT, TARGET, SAMPLE, DATE, COMMENT and more. The header gives the instrument settings (scan axis, scan mode, start/stop angles, step size, speed, etc.), followed by the pole-figure data, typically intensity values over a grid of tilts and rotations. The header begins with a signature such as TYPE..= and contains flags like XUNIT, YUNIT, FULL_SCALE, *GROUP_COUNT, etc.

Byte-signature identifiers that distinguish this format include the ASCII sequence starting at offset 0 that reads TYPE..=, and the presence of many of the keyword lines above. The data section follows the metadata, separated by BEGIN / END markers (or EOF), and often includes numerical tables with measured intensities corresponding to the geometry specified.

Saltpack Message Data File

We know that one ASC format is Saltpack Message Data File. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

SPIP ASCII Export SPM Text

SPIP ASCII Export SPM Text files store image and curve data generated by SPIP (Scanning Probe Image Processor) in a plain-text form that preserves the physical measurement dimensions. The format is used for exporting two-dimensional SPM (scanning probe microscopy) data and associated curves so they can be imported into analysis tools that do not support SPIP's proprietary formats.

Files are produced by SPIP when saving images or curves in ASCII (*.asc) format ("Save all in ASCII") so that measurements like scan length, pixel count, and offsets are retained. They are read and written by Gwyddion using its spip-asc module, which supports both importing and exporting of this SPIP ASCII SPM text format.

The file contains a header section in plain ASCII text lines, beginning with a signature line "#FileFormat=ASCII", then metadata and fields such as CREATED BY, X-LENGTH, Y-LENGTH, X-OFFSET, Y-OFFSET, X-PIXELS, Y-PIXELS. After a "START OF DATA" line the actual measurement values follow in a raster format corresponding to the pixels of the image or rows of the curve.

Symantec QandA Macro

Symantec Q&A macro files store recorded macros for the Q&A database/word-processor system developed by Symantec for MS-DOS. A macro file holds a set of predefined keystrokes and commands that automate repetitive tasks inside Q&A, such as navigating menus, opening databases, running reports, exporting data, setting formatting options, or invoking external programs.

Macros are created either by recording keys during a session or by writing them manually using Q&A's macro definition syntax. The macros are saved so that Q&A loads them on startup (if using the default macro file or one you specify) and provides access via its Macro menu.

The contents are plain ASCII text using Q&A macro commands inside definitional blocks. A macro begins with a block like <begdef> and ends with <enddef>. Within a block, there will usually be a hotkey identifier (e.g. <altx> or <nokey>), a name label <name>"...", and sequences of Q&A control codes (e.g. <vidon>, <f10>, <enter>, <esc>), and sometimes file paths or database filenames. Macros may also include programming logic or commands like @Macro(...) inside records or forms.

Files of this type start with the ASCII signature bytes for the characters "\<begdef\>" at offset zero, contain a matching "ENDDEF" string marking the end of macro definitions, and may use segments like <name>, <nokey>, <altk> etc to distinguish macros and define their behaviors.

WITec Exported Text Data

WITec Exported Text Data files store spectral measurements that have been exported from the WITec Project software as plain text. They preserve wavelength-axis data and one or more spectra (intensity vs wavelength), allowing further analysis in programs outside WITec. These files are intended primarily for spectral or mapping data rather than for images per se.

The file is produced by selecting ASCII or "Table" export options in WITec. One format stores the wavelength values in the first column and each subsequent column contains one spectrum each; another variant splits the data into separate files for X and Y axes (often for mapping data) so that spatial layout can be reconstructed when accompanied by parameters like points per line and lines per image. Metadata such as spectrum labels or units may optionally be included in one or two header lines.

These files are read by tools such as Gwyddion via its witec-asc module, which expects regular sampling in spatial dimensions and treats spectra and maps accordingly. Not every variant supports writing or preserving full spatial metadata; in some cases positional information is lost and spectra are imported merely as graph curves.

A byte signature appears at the very start of some versions: at offset 0 the ASCII string "/ExportedASCII-File" identifies that it is a WITec exported ASCII data file.

Wyko OPD ASCII Data

Wyko OPD ASCII Data files are text‐based exports made by the Wyko Vision32 software for optical profilometry measurements. They record surface height information (optical path difference) as a formatted matrix of numbers, preceded by metadata that describes how to convert those numbers into physical units like height in nanometers and physical dimensions of the scan.

The header section contains lines with key parameter names and values such as "X Size", "Y Size", "Pixel_size", "Aspect", "Wavelength", and others. These define the number of data points in X and Y (Nx and Ny), the spacing between pixels, and the wavelength of the light source. After the header comes a special header line naming the upcoming data block (e.g. "RAW_DATA") followed by the matrix values. The numeric data are listed column‐by‐column in wrap‐around form, so that the first Ny values are the first column top-to-bottom, then the second column, etc.

Numerical values in the matrix may be integers or floating‐point. Integer values are converted via a "Mult" header field to waves, and then multiplied by the Wavelength to obtain height in nanometers. Floating‐point values are already in waves and require only multiplication by Wavelength. Any "bad value" (non-numeric in certain data fields) is handled specially, often marked or skipped.

A reliable internal signature starts at file offset 0 with the ASCII string "WykoASCIIDataFileFormat" followed by a comma at position 29. That helps distinguish Wyko OPD ASCII from other ASC formats.

Various apps that use files with this extension

These apps are known to open certain types of ASC files. Remember, different programs may use ASC files for different purposes, so you may need to try out a few of them to be able to open your specific file.

Help us help others

File.org helps thousands of users every day, and we would love to hear from you if you have additional information about ASC file formats, example files, or compatible programs. Please use the links below or email us at submit@file.org to discuss further.