File format

2 Patents

File type redirects here. File type may also refer to

Unix le types.

Patent law, rather than copyright, is more often used to

protect a le format. Although patents for le formats are
not directly permitted under US law, some formats encode data using patented algorithms. For example, using
compression with the GIF le format requires the use of a
patented algorithm, and though the patent owner did not
initially enforce their patent, they later began collecting
royalty fees. This has resulted in a signicant decrease
in the use of GIFs, and is partly responsible for the development of the alternative PNG format. However, the
patent expired in the US in mid-2003, and worldwide in
mid-2004.

A le format is a standard way that information is encoded for storage in a computer le. It species how
bits are used to encode information in a digital storage
medium. File formats may be either proprietary or free
and may be either unpublished or open.
Some le formats are designed for very particular types
of data: PNG les, for example, store bitmapped images
using lossless data compression. Other le formats, however, are designed for storage of several dierent types of
data: the Ogg format can act as a container for dierent
types of multimedia including any combination of audio
and video, with or without text (such as subtitles), and
metadata. A text le can contain any stream of characters, including possible control characters, and is encoded
in one of various character encoding schemes. Some le
formats, such as HTML, scalable vector graphics, and the
source code of computer software are text les with dened syntaxes that allow them to be used for specic purposes.

3 Identifying le type
Dierent operating systems have traditionally taken different approaches to determining a particular les format, with each approach having its own advantages and
disadvantages. Most modern operating systems and individual applications need to use all of the following approaches to read foreign le formats, if not work with
them completely.

3.1 Filename extension

Specications

Main article: Filename extension

File formats often have a published specication describing the encoding method and enabling testing of program
intended functionality. Not all formats have freely available specication documents, partly because some developers view their specication documents as trade secrets,
and partly because other developers never author a formal specication document, letting precedent set by other
programs dene the format.

One popular method used by many operating systems, including Windows, Mac OS X, CP/M, DOS, VMS, and
VM/CMS, is to determine the format of a le based on
the end of its namethe letters following the nal period.
This portion of the lename is known as the lename extension. For example, HTML documents are identied
by names that end with .html (or .htm), and GIF images by .gif. In the original FAT lesystem, le names
were limited to an eight-character identier and a threecharacter extension, known as an 8.3 lename. There
are only so many three-letter extensions, so, often any
given extension might be linked to more than one program. Many formats still use three-character extensions
even though modern operating systems and application
programs no longer have this limitation. Since there is no
standard list of extensions, more than one format can use
the same extension, which can confuse both the operating
system and users.

If the developer of a format doesn't publish free specications, another developer looking to utilize that kind of
le must either reverse engineer the le to nd out how to
read it or acquire the specication document from the formats developers for a fee and by signing a non-disclosure
agreement. The latter approach is possible only when a
formal specication document exists. Both strategies require signicant time, money, or both; therefore, le formats with publicly available specications tend to be supported by more programs.
1

3 IDENTIFYING FILE TYPE

One artifact of this approach is that the system can easily

be tricked into treating a le as a dierent format simply
by renaming itan HTML le can, for instance, be easily
treated as plain text by renaming it from lename.html to
lename.txt. Although this strategy was useful to expert
users who could easily understand and manipulate this information, it was often confusing to less technical users,
who could accidentally make a le unusable (or lose it)
by renaming it incorrectly.
This led more recent operating system shells, such as
Windows 95 and Mac OS X, to hide the extension when
listing les. This prevents the user from accidentally
changing the le type, and allows expert users to turn this
feature o and display the extensions.
Hiding the extension, however, can create the appearance
of two or more identical lenames in the same folder. For
example, a company logo may be needed both in .eps
format (for publishing) and .png format (for web sites).
With the extensions visible, these would appear as the
unique lenames CompanyLogo.eps and CompanyLogo.png. On the other hand, hiding the extensions would
make both appear as CompanyLogo.
Hiding extensions can also pose a security risk.[1] For
example, a malicious user could create an executable
program with an innocent name such as Holiday
photo.jpg.exe. The ".exe would be hidden and a user
would see Holiday photo.jpg, which would appear to be
a JPEG image, unable to harm the machine save for bugs
in the application used to view it. However, the operating
system would still see the ".exe extension and thus run
the program, which would then be able to cause harm to
the computer. The same is true with les with only one
extension: as it is not shown to the user, no information
about the le can be deduced without explicitly investigating the le. Extensions can be spoofed. Some Word
macro viruses create a Word le in template format and
save it with a .DOC extension. Since Word generally ignores extensions and looks at the format of the le these
would open as templates, execute, and spread the virus.
To further trick users, it is possible to store an icon inside
the program, in which case some operating systems icon
assignment for the executable le (.exe) would be overridden with an icon commonly used to represent JPEG
images, making the program look like an image. This issue requires users with extensions hidden to be vigilant
and never let the operating system choose with what program to open a le not known to be trustworthy (which
counteracts the idea of making things easier for the user).
This presents a practical problem for Windows systems
where extension-hiding is turned on by default.

happen to always be in specic locations in les of some

formats. Since the easiest place to locate them is at the
beginning, such area is usually called a le header when
it is greater than a few bytes, or a magic number if it is
just a few bytes long.
3.2.1 File header
The metadata contained in a le header are usually stored
at the start of the le, but might be present in other areas too, often including the end, depending on the le
format or the type of data contained. Character-based
(text) les usually have character-based headers, whereas
binary formats usually have binary headers, although this
is not a rule. Text-based le headers usually take up more
space, but being human-readable, they can easily be examined by using simple software such as a text editor or
a hexadecimal editor.
As well as identifying the le format, le headers may
contain metadata about the le and its contents. For example, most image les store information about image
format, size, resolution and color space, and optionally
authoring information such as who made the image, when
and where it was made, what camera model and photographic settings were used (Exif), and so on. Such metadata may be used by software reading or interpreting the
le during the loading process and afterwards.
File headers may be used by an operating system to
quickly gather information about a le without loading it
all into memory, but doing so uses more of a computers
resources than reading directly from the directory information. For instance, when a graphic le manager has to
display the contents of a folder, it must read the headers
of many les before it can display the appropriate icons,
but these will be located in dierent places on the storage
medium thus taking longer to access. A folder containing many les with complex metadata such as thumbnail
information may require considerable time before it can
be displayed.
If a header is binary hard-coded such that the header itself
needs complex interpretation in order to be recognized,
especially for metadata content protections sake, there is
a risk that the le format can be misinterpreted. It may
even have been badly written at the source. This can result
in corrupt metadata which, in extremely bad cases, might
even render the le unreadable.
A more complex example of le headers are those used
for wrapper (or container) le formats.
3.2.2 Magic number

3.2

Internal metadata

See also: Magic number (programming)

A second way to identify a le format is to use information regarding the format stored inside the le itself, either One way to incorporate le type metadata, often associinformation meant for this purpose or binary strings that ated with Unix and its derivatives, is just to store a magic

3.3

External metadata

number inside the le itself. Originally, this term was

used for a specic set of 2-byte identiers at the beginning
of a le, but since any binary sequence can be regarded as
a number, any feature of a le format which uniquely distinguishes it can be used for identication. GIF images,
for instance, always begin with the ASCII representation
of either GIF87a or GIF89a, depending upon the standard to which they adhere. Many le types, especially
plain-text les, are harder to spot by this method. HTML
les, for example, might begin with the string <html>
(which is not case sensitive), or an appropriate document
type denition that starts with <!DOCTYPE HTML>,
or, for XHTML, the XML identier, which begins with
<?xml. The les can also begin with HTML comments,
random text, or several empty lines, but still be usable
HTML.
The magic number approach oers better guarantees that
the format will be identied correctly, and can often determine more precise information about the le. Since
reasonably reliable magic number tests can be fairly
complex, and each le must eectively be tested against
every possibility in the magic database, this approach is
relatively inecient, especially for displaying large lists
of les (in contrast, le name and metadata-based methods need check only one piece of data, and match it
against a sorted index). Also, data must be read from
the le itself, increasing latency as opposed to metadata
stored in the directory. Where le types don't lend themselves to recognition in this way, the system must fall back
to metadata. It is, however, the best way for a program to
check if the le it has been told to process is of the correct format: while the les name or metadata may be altered independently of its content, failing a well-designed
magic number test is a pretty sure sign that the le is either corrupt or of the wrong type. On the other hand, a
valid magic number does not guarantee that the le is not
corrupt or is of a correct type.
So-called shebang lines in script les are a special case
of magic numbers. Here, the magic number is humanreadable text that identies a specic command interpreter and options to be passed to the command interpreter.
Another operating system using magic numbers is
AmigaOS, where magic numbers were called Magic
Cookies and were adopted as a standard system to recognize executables in Hunk executable le format and
also to let single programs, tools and utilities deal automatically with their saved data les, or any other kind of
le types when saving and loading data. This system was
then enhanced with the Amiga standard Datatype recognition system. Another method was the FourCC method,
originating in OSType on Macintosh, later adapted by
Interchange File Format (IFF) and derivatives.

3.3 External metadata

A nal way of storing the format of a le is to explicitly store information about the format in the le system,
rather than within the le itself.
This approach keeps the metadata separate from both the
main data and the name, but is also less portable than either le extensions or magic numbers, since the format
has to be converted from lesystem to lesystem. While
this is also true to an extent with lename extensionsfor
instance, for compatibility with MS-DOSs three character limitmost forms of storage have a roughly equivalent denition of a les data and name, but may have
varying or no representation of further metadata.
Note that zip les or archive les solve the problem of
handling metadata. A utility program collects multiple
les together along with metadata about each le and the
folders/directories they came from all within one new le
(e.g. a zip le with extension .zip). The new le is also
compressed and possibly encrypted, but now is transmissible as a single le across operating systems by FTP systems or attached to email. At the destination, it must
be unzipped by a compatible utility to be useful, but the
problems of transmission are solved this way.

3.3.1 Mac OS type-codes

The Mac OS' Hierarchical File System stores codes for
creator and type as part of the directory entry for each le.
These codes are referred to as OSTypes. These codes
could be any 4-byte sequence, but were often selected
so that the ASCII representation formed a sequence of
meaningful characters, such as an abbreviation of the applications name or the developers initials. For instance
a HyperCard stack le has a creator of WILD (from
Hypercards previous name, WildCard) and a type of
STAK. The BBEdit text editor has a creator code of R*ch
referring to its original programmer, Rich Siegel. The
type code species the format of the le, while the creator
code species the default program to open it with when
double-clicked by the user. For example, the user could
have several text les all with the type code of TEXT,
but which each open in a dierent program, due to having diering creator codes. This feature was intended so
that, for example, human-readable plain-text les could
be opened in a general purpose text editor, while programming or HTML code les would open in a specialized editor or IDE, but this feature was often the source of
user confusion as which program would launch when the
les were double-clicked was often unpredictable. RISC
OS uses a similar system, consisting of a 12-bit number
which can be looked up in a table of descriptionse.g.
the hexadecimal number FF5 is aliased to PoScript,
representing a PostScript le.

3 IDENTIFYING FILE TYPE

3.3.2

Mac OS X uniform type identiers (UTIs)

Main article: Uniform Type Identier

attributes can still be read and written by Win32 programs, but the data must be entirely parsed by applications.

A Uniform Type Identier (UTI) is a method used in Mac 3.3.4 POSIX extended attributes
OS X for uniquely identifying typed classes of entity,
such as le formats. It was developed by Apple as a re- On Unix and Unix-like systems, the ext2, ext3, ReiserFS
placement for OSType (type & creator codes).
version 3, XFS, JFS, FFS, and HFS+ lesystems allow the
The UTI is a Core Foundation string, which uses a storage of extended attributes with les. These include an
reverse-DNS string. Some common and standard types arbitrary list of name=value strings, where the names
use a domain called public (e.g. public.png for a Portable are unique and a value can be accessed through its related
Network Graphics image), while other domains can name.
be used for third-party types (e.g. com.adobe.pdf for
Portable Document Format). UTIs can be dened within
a hierarchical structure, known as a conformance hierar- 3.3.5 PRONOM unique identiers (PUIDs)
chy. Thus, public.png conforms to a supertype of public.image, which itself conforms to a supertype of pub- The PRONOM Persistent Unique Identier (PUID) is
lic.data. A UTI can exist in multiple hierarchies, which an extensible scheme of persistent, unique and unambiguous identiers for le formats, which has been deprovides great exibility.
veloped by The National Archives of the UK as part
In addition to le formats, UTIs can also be used for other of its PRONOM technical registry service. PUIDs can
entities which can exist in OS X, including:
be expressed as Uniform Resource Identiers using the
info:pronom/ namespace. Although not yet widely used
outside of UK government and some digital preserva Pasteboard data
tion programmes, the PUID scheme does provide greater
Folders (directories)
granularity than most alternative schemes.
Translatable types (as handled by the Translation
Manager)
3.3.6 MIME types
Bundles

MIME types are widely used in many Internet-related

applications, and increasingly elsewhere, although their
Frameworks
usage for on-disc type information is rare. These consist of a standardised system of identiers (managed by
Streaming data
IANA) consisting of a type and a sub-type, separated by
Aliases and symlinks
a slashfor instance, text/html or image/gif. These were
originally intended as a way of identifying what type of
le was attached to an e-mail, independent of the source
3.3.3 OS/2 extended attributes
and target operating systems. MIME types identify les
on BeOS, AmigaOS 4.0 and MorphOS, as well as store
The HPFS, FAT12 and FAT16 (but not FAT32) lesys- unique application signatures for application launching.
tems allow the storage of extended attributes with les. In AmigaOS and MorphOS the Mime type system works
These comprise an arbitrary set of triplets with a name, in parallel with Amiga specic Datatype system.
a coded type for the value and a value, where the names
are unique and values can be up to 64 KB long. There There are problems with the MIME types though; several
are standardized meanings for certain types and names organisations and people have created their own MIME
(under OS/2). One such is that the ".TYPE extended types without registering them properly with IANA,
attribute is used to determine the le type. Its value com- which makes the use of this standard awkward in some
prises a list of one or more le types associated with the cases.
le, each of which is a string, such as Plain Text or
HTML document. Thus a le may have several types. 3.3.7 File format identiers (FFIDs)
The NTFS lesystem also allows storage of OS/2 extended attributes, as one of the le forks, but this feature is merely present to support the OS/2 subsystem (not
present in XP), so the Win32 subsystem treats this information as an opaque block of data and does not use
it. Instead, it relies on other le forks to store metainformation in Win32-specic formats. OS/2 extended

File format identiers is another, not widely used way to

identify le formats according to their origin and their
le category. It was created for the Description Explorer
suite of software. It is composed of several digits of the
form NNNNNNNNN-XX-YYYYYYY. The rst part
indicates the organisation origin/maintainer (this number

4.2

Chunk-based formats

represents a value in a company/standards organisation

database), the 2 following digits categorize the type of
le in hexadecimal. The nal part is composed of the
usual le extension of the le or the international standard
number of the le, padded left with zeros. For example,
the PNG le specication has the FFID of 00000000131-0015948 where 31 indicates an image le, 0015948
is the standard number and 000000001 indicates the ISO
Organisation.

5
The containers scope can be identied by start- and endmarkers of some kind, by an explicit length eld somewhere, or by xed requirements of the le formats denition.
Throughout the 1970s, many programs used formats of
this general kind. For example, word-processors such as
tro, Script, and Scribe, and database export les such as
CSV. Electronic Arts and Commodore-Amiga also used
this type of le format in 1985, with their IFF (Interchange File Format) le format.

A container is sometimes called a chunk, although

chunk may also imply that each piece is small, and/or
Another but less popular way to identify the le format that chunks do not contain other chunks; many formats
is to examine the le contents for distinguishable pat- do not impose those requirements.
terns among le types. The contents of a le are a se- The information that identies a particular chunk may
quence of bytes and a byte has 256 unique permutations be called many dierent things, often terms including
(0255). Thus, counting the occurrence of byte patterns eld name, identier, label, or tag. The identithat is often referred as byte frequency distribution gives ers are often human-readable, and classify parts of the
distinguishable patterns to identify le types. There are data: for example, as a surname, address, rectanmany content-based le type identication schemes that gle, font name, etc. These are not the same thing as
use byte frequency distribution to build the representa- identiers in the sense of a database key or serial number
tive models for le type and use any statistical and data (although an identier may well identify its associated
mining techniques to identify le types [2]
data as such a key).
3.3.8

File content based format identication

With this type of le structure, tools that do not know

certain chunk identiers simply skip those that they do
not understand. Depending on the actual meaning of the
4 File structure
skipped data, this may or may not be useful (CSS explicThere are several types of ways to structure data in a le. itly denes such behavior).
The most usual ones are described below.
This concept has been used again and again by RIFF
(Microsoft-IBM equivalent of IFF), PNG, JPEG storage,
DER (Distinguished Encoding Rules) encoded streams
4.1 Unstructured formats (raw memory and les (which were originally described in CCITT
X.409:1984 and therefore predate IFF), and Structured
dumps)
Data Exchange Format (SDXF).
Earlier le formats used raw data formats that consisted Indeed, any data format must somehow identify the
of directly dumping the memory images of one or more signicance of its component parts, and embedded
structures into the le.
boundary-markers are an obvious way to do so:
This has several drawbacks. Unless the memory images
also have reserved spaces for future extensions, extending
and improving this type of structured le is very dicult.
It also creates les that might be specic to one platform
or programming language (for example a structure containing a Pascal string is not recognized as such in C). On
the other hand, developing tools for reading and writing
these types of les is very simple.
The limitations of the unstructured formats led to the development of other types of le formats that could be
easily extended and be backward compatible at the same
time.

4.2

Chunk-based formats

In this kind of le structure, each piece of data is embedded in a container that somehow identies the data.

MIME headers do this with a colon-separated label

at the start of each logical line. MIME headers cannot contain other MIME headers, though the data
content of some headers has sub-parts that can be
extracted by other conventions.
CSV and similar les often do this using a header
records with eld names, and with commas to mark
the eld boundaries. Like MIME, CSV has no provision for structures with more than one level.
XML and its kin can be loosely considered a kind of
chunk-based format, since data elements are identied by markup that is akin to chunk identiers.
However, it has formal advantages such as schemas
and validation, as well as the ability to represent
more complex structures such as trees, DAGs, and
charts. If XML is considered a chunk format, then

7
SGML and its predecessor IBM GML are among
the earliest examples of such formats.
JSON is similar to XML without schemas, crossreferences, or a denition for the meaning of repeated eld-names, and is often convenient for programmers.
Protocol buers are in turn similar to JSON, notably replacing boundary-markers in the data with
eld numbers, which are mapped to/from names by
some external mechanism.

4.3

Directory-based formats

This is another extensible format, that closely resembles

a le system (OLE Documents are actual lesystems),
where the le is composed of 'directory entries that contain the location of the data within the le itself as well
as its signatures (and in certain cases its type). Good examples of these types of le structures are disk images,
OLE documents and TIFF images.

See also
Audio le format
Chemical le format
Digital container format
Document le format
DROID le format identication utility
File (command), a le type identication utility
File Formats, Transformation, and Migration (related wikiversity article)
File conversion
Future proong
Graphics le format summary
Image le formats
List of archive formats
List of le formats
List of lename extensions (alphabetical)
List of free le formats
List of motion and gesture le formats
Magic number (programming)
List of le signatures, or magic numbers
Object le
Video le format
Windows le types

EXTERNAL LINKS

6 References
[1] PC World (23 December 2003). Windows Tips: For Security Reasons, It Pays To Know Your File Extensions.
Retrieved 20 June 2008.
[2] File Format Identication.

Extended Attribute Data Types. REXX

Tips & Tricks, Version 2.80. Retrieved
February 9, 2005.
Extended Attributes used by the WPS.
REXX Tips & Tricks, Version 2.80. Retrieved February 9, 2005.
Extended Attributes - what are they and
how can you use them ?". Roger Orr. Retrieved February 9, 2005.

7 External links
Open Directory Data Format links - File types resources on DMOZ
Best Practices for File Formats, US: Stanford University Libraries, Data Management Services (The
le formats you use have a direct impact on your
ability to open those les at a later date and on the
ability of other people to access those data)

Text and image sources, contributors, and licenses

8.1

Text

File format Source: https://en.wikipedia.org/wiki/File_format?oldid=756476452 Contributors: Damian Yerrick, Tuxisuau, Brion VIBBER, Bryan Derksen, Zundark, The Anome, Wayne Hardman, Karl E. V. Palmen, PierreAbbat, Ryguasu, Hirzel, B4hand, Lightning~enwiki, Bob Jonkman, Twilsonb, Patrick, RTC, Nixdorf, Psi~enwiki, Tannin, Ahoerstemeier, Stan Shebs, Mac, J-Wiki, Error, IMSoP, Ww, Dysprosia, Markhurd, Furrykef, Joy, AnonMoos, Ldo, Phil Boswell, Robbot, Chealer, RedWolf, Geo97, Yacht, Wikibot,
Wereon, Tea2min, Art Carlson, Hagedis, Dissident, Niteowlneils, Mboverload, AlistairMcMillan, Vadmium, Beland, OverlordQ, Marc
Mongenet, Rich Farmbrough, Smyth, Kop, Kiand, Sajt, Nigelj, Stesmo, R. S. Shaw, Ranma~enwiki, Jrme, Guy Harris, CyberSkull,
Atlant, Mikenolte, Mrtngslr, Kbolino, Simetrical, Reinoutr, Asteron, Uncle G, Jacobolus, Phillipsacp, NeoChaosX, Gengiskanhg, SDC,
Joerg Kurt Wegner, Marudubshinki, Graham87, Raaele Megabyte, Drrngrvy, Ysangkok, Spudtater, RexNL, Sderose, KirtWalker, DaGizza, ColdFeet, Wavelength, Phantomsteve, Taejo, SpuriousQ, IByte, Yuhong, Gaius Cornelius, Dureo, JulesH, Putz~enwiki, Bota47,
Elkman, CWenger, Ian Fieggen, David Biddulph, Allens, Mhkay, SmackBot, Incnis Mrsi, Adam Mirowski, Shoy, Unyoyega, Gilliam,
Thumperward, Oli Filth, Nbarth, Colonies Chris, Can't sleep, clown will eat me, Abmac, Dreadstar, Warren, Mwtoews, Henning Makholm,
Bogsat, Jna runn, Xandi, Fsuarez2005, WalterMB, 16@r, Loadmaster, EdC~enwiki, Hu12, Shoeofdeath, Robust Physique, Simeon,
RageRiot, Enoch the red, Kozuch, PamD, Thijs!bot, Epbr123, Hasan.Z, Bobblehead, Davidhorman, Philippe, Escarbot, Mentisto, AntiVandalBot, Gioto, OMD, MikeLynch, JAnDbot, MER-C, Malpertuis, Psicorps, Tedickey, Ccodere, Nposs, TheDwoo, Wikianon, Aluvia,
Ineable3000, Conquerist, MartinBot, STBot, Jim.henderson, Speck-Made, Trusilver, Theo Mark, Petrwiki, Nemo bis, AhmadSherif,
Vinamra2004, Bushcarrot, Cometstyles, Joeinwap, Boijunk, AlnoktaBOT, Matthieu.evrard, Orie0505, Canaima, Jackfork, Wiae, Pious7,
AJRobbins, Phreaka Dude, Arslansheikh, SieBot, Zuurman, Smsarmad, Nickols k, Grndrush, Allmightyduck, Jdaloner, Averagebloke,
Ashenfelder, Withouttrace, The Stickler, StaticGull, ClueBot, GorillaWarfare, The Thing That Should Not Be, Jewers, Enthusiast01, DragonBot, MorrisRob, TobiasPersson, ANOMALY-117, SchreiberBike, La Pianista, Inspector 34, Thingg, Fred4816, MelonBot, InternetMeme, XLinkBot, DotWhat, SilvonenBot, RP459, Addbot, Ghettoblaster, LP, Tanhabot, Cst17, CarsracBot, AnnaFrance, Tassedethe,
Jarble, Yobot, AnomieBOT, Piano non troppo, Padeas, Extensionpedia, A.amitkumar, M2545, Michelin106, HRoestBot, Jonesey95,
Hoo man, Barras, Ahm irf, Vrenator, Lewisluo, Christopherhalliwell, Mean as custard, Dewritech, K6ka, Ronk01, ClueBot NG, SpikeTorontoRCP, Gunnerjack14, Oddbodz, BG19bot, Wiki13, Tom Pippens, HMman, Alikjinda, Hopeoight, BattyBot, ,
Prof. Squirrel, Tagremover, YFdyh-bot, Khazar2, Junior5a, Hmainsbot1, Mogism, Isarra (HG), Bumblebritches57, Condorcraft110, Jemee012, Babitaarora, Wilster.clark, Ugog Nizdast, Ginsuloft, Spacenut42, Neosamardzic1223434343000, Csusarah, Baybaym, Sandradiaz016, CamelCase, Juan j funes, KH-1, Innite0694, Supdiop, Dr Liton, Ugultopu, Reidgreg, Mxbu41, Justeditingtoday and Anonymous:
275

8.2

Images

File:Ambox_important.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/b4/Ambox_important.svg License: Public domain Contributors: Own work, based o of Image:Ambox scales.svg Original artist: Dsmurat (talk contribs)
File:Question_book-new.svg Source: https://upload.wikimedia.org/wikipedia/en/9/99/Question_book-new.svg License: Cc-by-sa-3.0
Contributors:
Created from scratch in Adobe Illustrator. Based on Image:Question book.png created by User:Equazcion Original artist:
Tkgd2007
File:Text_document_with_red_question_mark.svg Source: https://upload.wikimedia.org/wikipedia/commons/a/a4/Text_document_
with_red_question_mark.svg License: Public domain Contributors: Created by bdesham with Inkscape; based upon Text-x-generic.svg
from the Tango project. Original artist: Benjamin D. Esham (bdesham)
File:Wiktionary-logo-v2.svg Source: https://upload.wikimedia.org/wikipedia/commons/0/06/Wiktionary-logo-v2.svg License: CC BYSA 4.0 Contributors: Own work Original artist: Dan Polansky based on work currently attributed to Wikimedia Foundation but originally
created by Smurrayinchester

8.3

Content license

Creative Commons Attribution-Share Alike 3.0