This page was created specifically to guide graphic designers and creative directors who are designing for the web.


We encourage you to bookmark the page and come back to check for updates.
Last update December 10, 2016


This page helps identify common issues during the migration of a design/template to the web (slicing). It’s critical that you understand the limitations and considerations of the process to set expectations for the final product. Not understanding the information in this document can cause confusion later on or produce a result that looks different from the original design, or that differs from what you expected – and so we encourage you to contact us (details below) if you have any comments/questions/concerns. Moreover, not adhering to these standards can increase your budget, or even prohibit your project from beginning.

File formats
  • Layout submissions should be in the layered, PSD file-format. Proper naming and organization of layers into logical groups can greatly reduce slicing time. In some cases the project will require additional budgeting if your PSD file is ‘in a mess’.
  • In most situations, it's preferred to NOT use Layer Comps in Photoshop.
  • Please do not include frames that show your design inside a web browser, unless they are intended to be part of the programmed site. These can simply be cropped out to make slicing quicker & easier.
  • Blend modes (such as 'multiply') are something difficult to slice because it's dependent on the layer(s) below it. Blend modes should not be used unless it is the intention for the object/layer using a blend-mode to merge with the content below it.
  • Create a typography layer. This usually involves a list of all typographic elements such as H1, H2, etc, Paragraph, Em, Italics, Strong, Lists, Form labels, Blockquote, etc. We can provide an example Typography layer /group if required.


  • The dimension of your layout must be sized to the final desired width and height. The image width and height of the template you provide will become exactly the same on the web. In other words, send your template at 100% size. For example, if you send your design as 10,000px by 20,000px; it will appear this dimension in your browser!
  • We recommend even numbers for width/height/layouts as it makes it much easier to divide in half evenly (for centering, and overall positioning).
  • A good place to better understand popular browser dimensions is the GlobalStats StatCounter found here:


DPI and Quality
  • The design should be in 72dpi (dots per square inch). Do not send templates to be sliced for web in vector format.


  • Some end-users do not have certain fonts on their computer that your design or layout may be using. This can produce undesired results. As a safeguard, it is suggested to only use web-friendly fonts. A good site to verify safe fonts is: . 
    If a unique font (non web-friendly) is necessary, a workaround can be to create the text as an image. It’s important to note that this can inhibit search-ability, unless extra programming is added. This will mean more production time required.
  • Fonts selected from the Google Font Directory (GFD) are also acceptable. Note: users who do not have a GFD font on their computer may notice a render delay. Using one of these will also extra page load time. We recommend only using 1 or 2 at most.
  • A valuable and common icon font set is FontAwesome, we recommend using this in place of graphic icons as it can reduce load times for your coded site (and make it easier to maintain):
  • Note: some browsers will render fonts differently than others. For example Internet Explorer 7+ uses a built in anti-aliasing filter (soft edges) over the text where previous versions of this browser did not.
  • Most web browsers have client-side accessibility controls allowing them to change things such as the size of their fonts or the zoom level of the overall page. These client-side controls cannot (and should not) be overridden.
  •  Any text in your design that is intended to be true-text (not as part of an image) can not contain any special effects like anti-aliasing. When these effects are removed it can drastically change the appearance of these typefaces.
  • Fonts should also be rounded/whole numbers (so no 12.5px for example).
  • We strongly recommend against using Helvetica.


Standards and Browser based-considerations
  • Note: we slice designs in XHTML and CSS valid code as per the W3C specification guidelines. See:
  • Note: as a W3 standard, we use appropriate document types to give a website the best chance of looking the same in as many browsers as possible. However, some browsers have client-side specific controls that add effects to a website where others do not - these effects cannot be controlled. However, even with proper document type declarations some browsers use different margin, padding, and letter-spacing instructions that make it difficult for your design to appear exactly the same in all browsers. Sometimes it is best to choose a browser that you wish your design to look the best in.
  • As there is a multitude of web browsers (or ‘user-agents’) on a wide range of operating systems (like Windows, Linux/Unix, Mac, etc) it’s important to let us know if there is a specific user-agent you wish your website to work specifically for (i.e. Safari on an iPad). This is even truer for rare or uncommon user agents. As much as we develop for as many user-agents as possible, we generally focus on IE, Chrome, Firefox and Safari; meaning, if you were expecting otherwise but didn’t let us know, you might be disappointed.


  • Some user’s browsers and operating systems have accessibility settings that change appearances for people with disabilities; this is a client side controlled feature and your design may be distorted in these situations. For example, Windows-based operating systems allow the user to turn on 'high contrast colors' for people with vision impairment – these greatly affect the appearance of a website, and cannot be controlled by programming inside the website.


  • Assets used in the design (such as textures, icons, etc) should be supplied separately (i.e. in a 'resources' folder) to make it quicker & easier to convert to web.
  • Social Media Icons. If your design includes social media icons (share/follow buttons) it is important to reference where you pulled them from as the API's that provide them can be limited in the design customizability.


  • When creating a design intended for smart phones and mobile devices, it’s important to remember that a finger is not the same as a mouse pointer, and that certain mouse behaviors cannot be replicated by touch-screen devices (for example, "hovering" your mouse over something).
  • As a user-experience consideration, a finger is a lot less precise than a mouse pointer, and users will have a hard time clicking on small links or buttons; something to be mindful of. Recommended 'hitbox' of no less than 36x36 px.
  • When designing a 'responsive' site (one that adjusts to the screen size being used), consider the following:
    • be mindful of the difference between 'fluid' and 'fixed'. For Fixed responsive, we generally need a PSD for each 'breakpoint'. For fluid, you may have to provide additional 'in-between' breakpoints to show how elements adjust. Generally, Fluid responsive is a more costly exercise for the testing time alone.
    • your content should flow in an orderly/predictable manner: For example, if you have elements that sit side-by-side "A,B,C" on a desktop screen, but stack on top of one another in a different order on a mobile screen "A,C,B" this adds programming overhead and requires additional time to customize.
    • If you're unsure about the smallest breakpoint for responsive, we recommend designing to fit on a 320x568px screen: this is a mid range that seems to cover the majority of the modern smart phones.
  • Some devices have higher pixel density screens. So for any static graphics we recommend providing an alternate of that graphic that is double the resolution of the one that appears in the design. This will make the graphic appear much smoother on these high pixel density screens.
  • For each unique page type you are designing, please provide [at minimum] a layout in desktop, tablet (portrait), and mobile (portrait).


Brownie Points

These specifications are not necessary, but if you follow them - we will love you for it :) In all seriousness, following this section just saves you time & money.

  • Proper layer grouping, naming, organization.
  • Don't leave any 'test' or 'draft' layers that are no longer used in the final design but are vestigial remnants of early concepts. Even if they are hidden they can create confusion, it's best to simply remove them.
  • Create an annotation layer. This involves using a layer (or group of layers) to make notes related to certain functionalities or consideration during design-to-web. The notes should be simple but help direct the slicer with something that might have otherwise missed.
  • If you have a box-element in your design containing content, using guides will help us accurately replicate your margins in code.


Copyright and Legal
  • Any assets or files (including typography and content, stock photography, fonts, and so on) that you provide us are entirely your responsibility and it is implied you have proper permissions to use them. If you are to provide us with stolen or unlicensed materials, we cannot be held liable for any consequences that may result in using these with your website.
  • This document is owned by Webbuilders Group and cannot be duplicated or copied without proper consent.

Comments or Questions? We encourage you to ask us!

Contact Us!